Tuple spread syntax

[tynanbe]

import gleam/dynamic.{DecodeErrors, Dynamic, field, int, list, string}
import gleam/io
import gleam/json
import gleam/list
import gleam/result

type DynResult(a) =
  Result(a, DecodeErrors)

pub opaque type Collector(a) {
  Collector(data: Dynamic, result: DynResult(a))
}

pub fn collector(data: Dynamic) -> Collector(#()) {
  Collector(data: data, result: Ok(#()))
}

// Spread tuple type's elements into another tuple type
pub fn get(
  from prev: Collector(a),
  with decoder: fn(Dynamic) -> DynResult(b),
) -> Collector(#(..a, b)) {
  let Collector(data, result) = prev
  case decoder(data), result {
    Ok(value), Ok(tuple) ->
      // Spread tuple's elements into another tuple
      #(..tuple, value)
      |> Ok
    Error(new_errors), Error(errors) ->
      errors
      |> list.append(new_errors)
      |> Error
    Error(errors), _ | _, Error(errors) -> Error(errors)
  }
  |> Collector(data: data)
}

pub fn apply(
  from prev: Collector(a),
  // Spread tuple type's elements into fn type's parameters
  to constructor: fn(..a) -> b,
) -> DynResult(b) {
  use args <- result.map(over: prev.result)
  // Spread tuple's elements into fn's arguments
  constructor(..args)
}

/// Begin Demo
pub type FooBar {
  FooBar(foo: Int, bar: String)
}

pub fn decode_foobar(data: Dynamic) -> DynResult(FooBar) {
  collector(data)
  |> get(field("foo", of: int))
  |> get(field("bar", of: string))
  |> apply(to: FooBar)
}

pub fn decode_foobars(data: String) -> Result(List(FooBar), json.DecodeError) {
  let decoder = list(of: decode_foobar)
  json.decode(from: data, using: decoder)
}

pub fn main() {
  let data =
    "
    [
      {
        \"foo\" : 0,
        \"bar\" : \"a\"
      },
      {
        \"foo\" : 1,
        \"bar\" : \"b\"
      }
    ]
  "

  data
  |> decode_foobars
  |> io.debug
}

Thinking about the current, undesirable fnN pattern (e.g. for decoders), I started from @schurhammer's recent idea, then came to the conclusion that it might be pretty clean and simple if we could spread tuples into at least other tuples and fn args, and spread tuple types into other tuple types and fn type parameters. Somewhat naively, it seems the type system would still be able to help as much as it does now. This would also open up other possibilities like building up fn args recursively for other use cases; there is certainly more to think about in this regard.

Here's a gist for an (unsafe, currently) proof of concept for the above code, targeting Erlang.

Other thoughts

Tuples are a bit like anonymous records, but otherwise a unique data type, so perhaps having a spread syntax for them in the type system and otherwise won't be too confusing, in case anyone wonders why they're "special."

Perhaps the spread syntax could be extended for records as well.

[lpil]

The two features here are being able to append to tuples, and being able to call functions with tuples as arguments, is that right?

It seems to be quite clear what the code does and how codegen would work, that's nice.

One thing to consider is that appending to a tuple means copying the entire tuple, it's not efficient like prepending to a list. With small tuples this is fine, but I worry that some folks may try and use tuples like arrays with this feature, and it's likely not a pattern we want to encourage.

It's unclear to me how this works at the type level. For example, what is a in #(..a, b) and fn(..a) -> b. It's not like a type parameter as it exists today in Gleam as it cannot be any type, it has to specifically be a tuple.

This reminds me a lot of row types in Elm, PureScript, etc. It's very easy to get very bad error messages here coming from type parameters, so we'd need to think carefully about that.

[tynanbe]

Those are great points! And yes, that's correct re the proposed features, except that it remains to be seen/decided whether it's possible to spread a tuple at any point in another tuple or a function's arguments, or even have multiple spreads in one place.

For example

let a = 1
let b = #(2, "3")
let c = "4"
let maybe_valid_tuple = #(a, ..b, c)
let maybe_valid_fn_call = fn(a, ..b, c)
let maybe_valid_tuple = #(a, ..b, c, ..b, "5")

Hopefully, in practice, tuples will almost always remain somewhat small. I don't see this being a common pattern, thinking about it now, just as the use cases it enables are also not that common, at least in my experience.

The type annotation syntax could possibly be clearer with some alternative notation. a in #(..a, b) is meant to be all the elements of a, and a would have to be some tuple for that syntax to be valid in the first place. Similarly, fn(..a) -> b would require that a is some tuple, and the fn's parameters are identical to a's elements. In that regard, having a ..generic typevar in any signature would narrow the type of generic.

Looking at it a bit more this morning, assuming some version of the type-level features is indeed possible, these features allow for dynamic.decode instead of dynamic.decodeN and function.apply instead of function.applyN functions in stdlib, but I'm not seeing how they could work for function.curry, unfortunately.