Type Signatures for Functions

[jdunkerley]

Having just cleared up a load of mismatch function type signatures the question occurs on whether we should review.

Currently we have:

Any.my_function : Integer -> Text
Any.my_function self that =

When we add or reorder parameters this can easily get out of line (see #5979).

We also have the option of pairing the parameters and the type:

Any.my_function self that:Integer =

However, this lacks the ability to have a return type specified, but does pair the type and parameters together making maintenance easier. My suggestion would be that we expand this syntax a little further to include a return type:

Any.my_function self that:Integer -> Text =

This would make keeping them in-line simpler and cleaner.

What do people think? cc: @radeusgd @JaroslavTulach @sylwiabr @wdanilo

[radeusgd]

I completely agree that the proposed syntax will make maintenance easier.

Our functions in Enso tend to take a lot of arguments, so having some correspondence between the actual arguments and their types will be very useful.

Currently, signatures with 5+ arguments are just hard to read too - because I have to count which type label refers to which argument. The proposed solution will not only be more maintainable, but also more readable.

[JaroslavTulach]

The proposed syntax seems less Haskell-like and more Scala-like. Parser shalln't have problem supporting the new syntax. Personally I don't like the return syntax as my_function self -> Text =, however.

Anyway the current syntax is errorprone I just had to fix one such error in my code: 74691a7 - it is so easy to get the arity wrong!

[jdunkerley]

Happy to go with any syntax - just felt like we need something better than we currently have.

[wdanilo]

I like the proposed syntax, it matches well IMO the design of the language. Let's do it :)

[JaroslavTulach]

The classical syntax -> -> isn't going away - we need a way to type a function variable, right @wdanilo?

[JaroslavTulach]

"Type a function variable" - what do you mean by that?

Any.my_function self that:(Integer -> Text) =

that is a variable of "function type". Another example:

main = 
    mul:(Number -> Number -> Number) = (x-> y-> x * y)
    mul 6 7

mul is a variable and it has some "function type".

[wdanilo]

@jdunkerley all clear. What about my comment above - do you think this syntax works well? :)

[jdunkerley]

I like generally but feel Any.my_function self that:Integer->Text should probably be resolved to

Any.my_function self that:Integer -> Text
i.e. that is an Integer and Text is the return.

The developer would need to bracket to say that is a function taking an Integer returning Text.

Its back to brackets making things clearer as with maths on order of operation.

[jdunkerley]

For the variable (or inline function) I think mul:(Number -> Number -> Number) = (x-> y-> x * y) is clear but we should also allow the
mul x:Number y:Number -> Number = x*y as an inline definition too.

[wdanilo]

I like generally but feel Any.my_function self that:Integer->Text should probably be resolved to

Any.my_function self that:Integer -> Text i.e. that is an Integer and Text is the return.

The developer would need to bracket to say that is a function taking an Integer returning Text.

Its back to brackets making things clearer as with maths on order of operation.

We can't do it, as it will be breaking our space-aware precedence, making all other parts of the language not consistent :( If there is no space = the thing is bound really strong.

Regarding top-level vs local function defs, I believe that always the same rules apply for them, so of course, if we chose a syntax here, it should work in all similar cases.