Gleam: Labelled function arguments

[ghost]

imo, optionally named function arguments (like in OCaml) would be meaningful

[lpil]

I agree, that would be a nice feature! I could see named arguments for both functions and enums being very useful. Let's add this to the TODO list.

I'm open to suggestions for the syntax.

[lpil]

Some discussion in the Rust community https://internals.rust-lang.org/t/pre-rfc-named-arguments/3831/196

[lpil]

Here is a Swift inspired syntax where the names of the labels do not have to be the same as the names used within the function. This is useful as the names can be changed without it being a breaking change, and it encourages selection of names that are best suited for the definition and the call site, rather than a compromise.

pub fn sub(string, from as position, remove as length: Int) {
  // ...
}

sub("Hello", from: 2, remove: 4)

We may want a shorthand if the variable name and the label are the same.

Some information on Swift's approach:
https://docs.swift.org/swift-book/LanguageGuide/Functions.html

[tmbb]

We may want a shorthand if the variable name and the label are the same.

I think that's overcomplicating the syntax for a very little gain.

[lpil]

Hi @tmbb ! So you would prefer not to have the shorthand syntax for when the variable name and label are the same?
If you have some code snippets to share that would be appreciated, thank you :)

[tmbb]

So you would prefer not to have the shorthand syntax for when the variable name and label are the same?

Well, maybe having the abbreviation would save a lot of typing, IDK. But the point I want to carry across is that Gleam already seems syntactically very complex, and adding more complexity on top of it doesn't seem like the correct thing to do IMO. But I'm very partial towards simple syntax, others are free to disagree 😄

[lpil]

Gleam already seems syntactically very complex

This is a good perspective to share, thank you! I've been working to make the grammar as small as possible so I would definitely be interested in examples of the complexity.

Currently I believe we're very small (on similar levels to Erlang!) and much much simpler than Elixir (our parser is ~600 lines compared Elixir's ~3000) but I'm sure there's improvements we can make before we stabilise the syntax.

[tmbb]

so I would definitely be interested in examples of the complexity.

It's not thaaat complex, to be fair. It's just that having very complex things inside function heads seems inelegant to me. But that is just my opinion...

[lpil]

Could you give an example of the very complex things? Thanks

[tmbb]

Could you give an example of the very complex things? Thanks

To me, this is simple:

pub fn sub(string, from as position, remove as length: Int) {
  // ...
}

but being able to have something like:

pub fn sub(string, #from, remove as length: Int) {
  // ...
}

(where #from is equivalent to from as from), which saves just a couple of characters, seems more complex than it should. All of this is subjective, though...

[lpil]

That's great, thank you :)

[OvermindDL1]

I personally find the xxx as yyy exceptionally hard to read for some reason. I don't know which side is the public and which is internal, I don't know why the right has the typing indicator but the left doesn't (why not remove: Int as length for example). And I'm not sure why you would want different public and internal names, doesn't that mean that one side or the other is misnamed?

[lpil]

After writing some Gleam today using this new syntax I am inclined to agree, it is very easy to get wrong. I shall try some more things :)