Open WhiteBlackGoose opened 2 years ago
func(1, 2)(3)
will not play well with function overloading, if func
has an overload with two arguments the compiler will be confused.
If function overloading is discarded, which i think is a good idea, then I'd still prefer to use the "." versions as partial application.
Given an function f
that receives 2 integers and returns 1 integer ( int int -> int
):
1.f
partially applies 1
to f
, the output of this expression would be a function of type int -> int
(1, 2).f
partially applies 1
and 2
to f
, creating a function of type () -> int
Calling the function always follows one pattern: f()
the parentheses come after the function, and partial application always is a.f
with a .
in between.
This dot notation also facilitates interfaces through the use of higher order functions, although it makes it explicit:
Given the type: Reader: function() []byte
, and the function ReadAll
of type Reader -> []byte
. One could use a.Read
to create a Reader
and pass it to ReadAll
:
var Data : []byte = ReadAll(a.Read)
This has the downside of making interfaces with multiple method signatures be hard to do, you'd either have to create a struct with a bunch of functions as fields, pass multiple parameters to functions or have a syntax sugar to do the hard work for you.
But assuming this language will need something to drive operator overloading, it may be necessary to have all operators be infix functions, and to make the compiler disambiguate between function names, kinda like Haskell.
Just my 2 cents
The problem with overloading is totally valid. And if we want to keep C# interop, yeah we need to restrict on the syntax a bit.
Assume we have
Then we could make those valid:
This is just an idea, but might add something to the final design