Labels punning

[giacomocavalieri]

I think Gleam would benefit from allowing label punning, that is a shorthand way to deal with labelled arguments.

What we currently do if we want to use labelled arguments in pattern matching looks like this:

pub type Wibble {
  Wibble(wibble: String, wobble: String)
}

// this is a bit verbose and repetitive
let Wibble(wibble: wibble, wobble: wobble) = todo

When pattern matching (or building a record), using labels instead of relying on the arguments' position can be a great way to avoid subtle bugs that would pop up in case of refactorings to the type definition. Imagine we did this:

let Wibble(wibble, wobble) = todo

And then the original definition changed to:

 pub type Wibble {
-  Wibble(wibble: String, wobble: String)
+  Wibble(wobble: String, wibble: String)
 }

The type system wouldn't be able to catch this subtle bug and we would have swapped wibble and wobble in the pattern matching I showed in the example above.
However, nothing would break if we used labels instead.

The problem is that having to repeat the name of the label twice can get quite annoying (and I must admit I usually end up using positional arguments instead because I can't be bothered writing everything twice).
Of course I could just use shorter names to bring labelled arguments into scope:

let Wibble(wibble: w1, wobble: w2) = todo

That would for sure solve my problem of repeating the label name twice but now my code using those arguments will be harder to read and littered with hard to understand variable names, I do want to use the label name!

While I'm aware that Gleam optimises for explicitness over terseness, I think this would be a really nice addition to make using labelled arguments less painful.

What would this look like

These definitions will be used in the following examples:

pub type Wibble {
  Wibble(wibble: String, wobble: String)
}

pub fn wibbler(wibble one: String, wobble other: String) { todo }

Record pattern matching

Just providing the label followed by : would mean the same as writing <label-name>:<label-name>, bringing it into scope:

pub fn examples(wibble: Wibble) {
  // --- In let/let-assert patterns
  // This:
  let Wibble(wobble:, wibble:) = wibble
  // would be the same as:
  let Wibble(wobble: wobble, wibble: wibble) = wibble
  
  // --- In case matches
  case wibble {
    // This:
    Wibble(wobble:, wibble:) -> todo
    // would be the same as:
    Wibble(wobble: wobble, wibble: wibble) -> todo
  }
}

Record construction

Passing <label-name>: to a record constructor would be the same as writing <label-name>:<label-name>:

pub fn examples() {
  let wibble = todo
  let wobble = todo

  // -- Record constructors
  // This:
  Wibble(wobble:, wibble:)
  // would be the same as:
  Wibble(wobble: wobble, wibble: wibble)

  // -- Record updates
  // This:
  Wibble(..todo, wobble:)
  // would be the same as:
  Wibble(..todo, wobble: wobble)
}

Since that's just some shorthand notation to pass in a labelled argument with the same name as the label all the same rules would apply.

Function calls

@hayleigh-dot-dev pointed out that the same behaviour could apply uniformly to labelled function arguments, not just constructors (since those are just functions themselves):

pub fn examples() {
  let wibble = todo
  let wobble = todo

  // -- In a function call
  // This:
  wibbler(wibble:, wobble:)
  // would be the same as:
  wibbler(wibble: wibble, wobble: wobble)

  // -- With only some labelled arguments
  // This:
  wibbler(todo, wobble:)
  // would be the same as:
  wibbler(todo, wobble: wobble)
}

Once again, all the same rules that already exist for labelled arguments would apply here as well (no unlabelled arguments after labelled ones, ...)

Other things to point out

Here's some considerations I think are worth pointing out from Discord's discussion thread:

• This can't be a breaking change so we can't add a new reserved keyword just for this
• We don't want :<label-name> because that's Elixir's syntax for defining an atom and that would end up being quite confusing for Elixir folks trying Gleam out
• Having the : after the label name would also make things easier to refactor if one wants to change the name of the labelled argument: just slap a name after it

  - Wibbler(wibble:, wobble:) -> wibble + 1
  + Wibbler(wibble: n, wobble:) -> n + 1

   Wibbler(
  -  wibble:,
  +  wibble: n,
     wobble:,
   ) -> todo

[lpil]

Hello!

This is the first time I've heard this being suggested for expressions as well as patterns. Was that included in the design so that expressions mirror patterns? Or do you think there are strong motivations for expanding the expression language too? You've only given motivations for patterns here.

Do we have any other suggestions for syntax?

[hayleigh-dot-dev]

Or do you think there are strong motivations for expanding the expression language too

Pretty much every Lustre application will use a record for it's Model and non-trivial apps will have many branches in their update function that update this record and it is very common to have updates in the form of Model(..model, thing: thing)

• Model(..model, value: value, length: length): https://github.com/lustre-labs/lustre/blob/dee571dd08576221fed28b2851e8dfe26a8129f6/examples/03-controlled-inputs/src/app.gleam#L40

• Model(..model, dependency_map: dependency_map, ...): https://github.com/willemclarke/whats-changed-gleam/blob/7c16e32ad940bfb59be01be30155ee94b69f9f78/client/src/client.gleam#L178

• Model(search_results: search_results, index: index, ...): https://github.com/ghivert/gloogle/blob/main/apps/frontend/src/data/model.gleam#L27

• Model(..model, sides: sides): https://github.com/0xca551e/n-sided-lucy/blob/80c50656572db4d30c5347a5c2a74932ccd8a813/src/main.gleam#L222

• Card(..card, content: content, length: length): https://github.com/mrgleam/crappy-board/blob/main/src/card.gleam#L31

I don't mean to be obtuse showing up with receipts, only to point out that this pattern is really common in Lustre code and would be made quite a bit nicer if we had field punning for updates!

[lpil]

In the examples you've given there having the value be a variable with the same name is a minority, and having tried editing the code to use the suggested syntax I didn't find it clearer and most the time it wasn't more concise due to the other fields being updated.

I'm not against it, just not as clear to me what the benefits are, and I want to avoid language expansion as much as possible.

[bonsairobo]

One benefit: less typing

[giacomocavalieri]

If it were just for the less typing I don't think this would be a really compelling proposal: Gleam doesn't really optimise for terseness 😁

I think the main benefit we could get from this is with pattern matching as it could encourage people using labelled arguments instead of positional ones without making it a hassle. For record building/updating I felt it would be nice if it were homogenous with how patterns work, I would find confusing being able to write Wibble(wibble:) in a pattern but get an error for trying it in a constructor... sadly I don't have any satisfying motivation other than "I feel it should be like this"

We could always start with just expanding patterns with punning and hear if other people feel the same, or actually find it confusing

[mooreryan]

Do we have any other suggestions for syntax?

Not really suggesting one particular style, but this survey I put together has examples of punning from a few different languages and could be useful for comparison.

[inoas]

if it is just about safety the option to enforce labels during declaration and calling constructors would also be on the table?

[apainintheneck]

This seems similar to the syntax added to Ruby in v3.1 which is nice at times but ugly at other times. In my opinion, it seems like an expert friendly feature that would make Gleam codebases harder to reason about for people just starting out with the language. You also run into the following formatting problem occasionally in Ruby when using it with kwargs or when creating hashes.

do_something(
  one:,
  two:,
  three:,
  four: another_name,
  five:,
  six:,
)

If it is restricted to only pattern matching, I can see a better argument for it. I think having a reduced scope would make it less confusing.

[bonsairobo]

What is the "formatting problem"?

[apainintheneck]

It's the contrast shown by the Ruby snippet above between the kwargs that are declared implicitly and ones that are declared explicitly that I find confusing. It almost feels like the ones that are declared implicitly are typos or missing something. When all kwargs are declared implicitly or all kwargs are declared implicitly it doesn't look so bad but when both are combined, it's not so clear. "Formatting problem" was probably the wrong phrase to describe that though.