Draco-lang / Language-suggestions

Collecting ideas for a new .NET language that could replace C#
75 stars 5 forks source link

Unified currying, partial application, methods and functions #26

Open WhiteBlackGoose opened 2 years ago

WhiteBlackGoose commented 2 years ago

Assume we have

func(1, 2, 3)

Then we could make those valid:

1.func(2, 3)
(1, 2).func(3)
(1, 2, 3).func()
1 func (2, 3)
(1, 2) func 3
func(1, 2)(3)
func(1)(2, 3)
func(1)(2)(3)
1.func(2)(3)
(1, 2).func(3)
(1, 2).func()(3)
(1, 2).func()()()()()(3)

This is just an idea, but might add something to the final design

padeir0 commented 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 ):

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

LPeter1997 commented 2 years ago

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.