Ceylon language

[Nick Sabalausky]

"bearophile" <bearophileHUGS at lycos.com> wrote in message 
news:io458e$elr$1 at digitalmars.com...
>
> Ceylon does not support method overloading (or any other kind of 
> overloading).
>

Eewww. Haxe is like that and it's nothing but a royal pain in the ass.

>
> If a value of type T can be null, it must be declared as type Optional<T>, 
> which may be abbreviated to T?
>
> String? name = process.args.first;
> if (exists name) {
>    writeLine("Hello " name "!");
> }
> else {
>    writeLine("Hello World!");
> }
>
> Use of an optional value must be guarded by the if (exists ... ) 
> construct. Therefore, NullPointerExceptions are impossible.
>
> This is exactly what I suggested for D in a enhancement request.
> It seems this kind of stuff is becoming a standard in new languages.
>

Yes, I'd *love* to see that in D, too.

>
> A method may declare multiple lists of parameters. The method body is 
> executed after arguments have been supplied to all parameter lists:
>
> Float add(Float x)(Float y) {
>    return x+y;
> }
>
> This is a kind of user defined and safe partial application, it's a cute 
> idea.
>
> Providing arguments to just one parameter list produces a method 
> reference:
>
> Float addOne(Float y) = add(1.0);
> Float three = addOne(2.0);
>
> (The point of all this is that we are able to provide all the 
> functionality of first-class and higher-order functions without needing to 
> resort to unnatural syntactic constructs inspired by the lambda calculus 
> notation.)
>

That really stikes me as a completly wrong way to do currying. Granted, I've 
never really used currying, but it seems it would only be appropriate for 
*outside* code to choose which to specify and not specify. Having the callee 
decide that seems to completely defeat the whole point. Although I guess it 
could be sometimes be useful as a really ugly hack to work around the lack 
of overloading.