[haXe] Void -> Void

[Nicolas Cannasse]

> Is this also understood in type declarations?  Ie. can I make my:
>    var runF = function(f : Void -> Void) : Void { return f(); };
>    var runG = function(g : (Void) -> Void) : Void { return g({}); };

Yes

> Actually, I'm a bit worried about the orthogonality of the notation:
>    Void -> Void  -  Takes 0 parameters
>    (Void) -> Void  -  Takes 1 Void parameter
>    Int -> Void  -  Takes 1 Int parameter.
> I admit, it's more aesthetics and I definitely understand that you're 
> not interested in messing around with the syntax, just to accommodate 
> this corner case.  However, it's another catch you can get caught on the 
> next time you do crazy higher-order polymorphic stuff.  Type errors can 
> be fiendishly hard to understand, and a pair of missing parentheses is 
> exactly something that can leave you scratching your head for hours.

That's the price for Void-parameters. It requires some differences
between "no-parameter" and "one or several Void parameters".
This is just a question of syntax : I feel like theses cases are rare
enough to justify a bit of additional syntactic disambiguation.

You could as well choose to have your parameters be of type "Dynamic"
when you don't need a value. That's a design choice, although I admit
Void seems the more logical way to go.

Please note that you can also define your own Void (NoParam) type :

enum NoParameter {
}

And that's it :)

> What about the curried example:
>    var s1 = function(x : Int) {
>               return function(y : Int) : Int {
>                 return x+y;
>               };
>             };
>    var s2 = function(x : Int, y : Int) : Int {
>               return x+y;
>             };
> Will their types be syntactically different?

Yes.
type(s1) : Int -> (Int -> Int)
type(s2) : Int -> Int -> Int

Nicolas