Support for optional arguments

[Sam647254]

I've been learning and using Mint for a couple of weeks now, and I'm enjoying the language so far. One feature that I miss in JavaScript/TypeScript is the ability to make arguments optional by specifying a default value:

function f(a, b = 0) {
  return a + b;
}

The idea that I have for Mint is something like this:

fun f(a : Number, b : Number = 0) : Number {
  a + b
}

Since type inference exists already for properties, optional arguments can have their types omitted as well:

fun f(a : Number, b = 0) : Number {
  a + b
}

One obvious issue that I can think of is that it won't mix well with partial application, since now f(a) could mean either partially applying the function or calling it with the optional argument. This can be solved by introducing a syntax for disambiguating the two scenarios, something like f(a) for the optional argument case, and f(a ...) for the partial application case.

I can help with the implementation.

Edit: Added the last sentence.

[gdotdesign]

I've been learning and using Mint for a couple of weeks now, and I'm enjoying the language so far.

That's great to hear! 😊

---

I'll convert this issue into a discussion, because this is a good issue to trigger a discussion about this topic (once I'm able to do so: community/community#2924 (comment)).

We have three competing features that solve the same thing:

• partial application
• function overloading
• default arguments

My preference would be function overloading with default arguments. I think that partial application does not have much use right now and also the hardest of the three to understand.

Connected to this topic is the safe access and safe call feature: maybe_record&.field, maybe_function&(value) which I would like to remove.

I'm interested to know how much these features are used:

• partial application
• safe access and safe call

I'm asking everyone to express their comments or ideas regarding this 🙂

[Sam647254]

Great! Thanks for the reply. Since I started this discussion, perhaps I can weigh in first.

Partial application is essential to the functional programming paradigm, as it's a simple way of creating new functions by filling in some of the arguments of an existing function. It's also necessary for creating chains of function calls via the pipe operator:

[1, 2, 3, 4]
|> Array.first Number.isOdd
|> Maybe.withDefault 1

Regarding function overloading, I'm equivocal about its inclusion in Mint, since its use cases can be fulfilled using enumerated types, but those coming from languages like C++/Java/C# may find code with overloaded functions more readable. This does add a small layer of complexity to the compiler, though, since functions can no longer be differentiated by their names alone.

Regarding default arguments, theoretically they can be emulated using overloaded functions (Java does this extensively) or enumerated types, but since JavaScript has default arguments built-in, compiling to them is relatively straightforward. The only problem that I can see would be using partial application alongside default arguments, like I previously mentioned.

I didn't even know that Mint has the safe access/call operators, but I agree that they don't really seem necessary, since it's effectively the same as calling Maybe.map; furthermore, if I understood the source code correctly, right now, if the record field or the return type is also a Maybe type, using the safe access/call operators will produce a nested Maybe, which will require an extra Maybe.flatten call. The Maybe.andThen function precisely eliminates this scenario. Thus, personally, I wouldn't mind if these operators are removed, since the benefit of the more concise syntax doesn't quite match up with the complexity of implementing it. Of course, these are just my opinions; I'm open to hearing what others think as well.