Ceylon language

[Nick Sabalausky]

"spir" <denis.spir at gmail.com> wrote in message 
news:mailman.3497.1302788057.4748.digitalmars-d at puremagic.com...
> On 04/13/2011 02:34 PM, bearophile wrote:
>
>>
>> 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.
>
> +++
>
> But I guess optionality could, and should, extend to non-ref types; thus, 
> null is just a particular case of non-existence. And this would apply 
> especially on function parameters:
>    void f (int i?) {...}
>

Oh absolutely. Haxe has nullable-primatives which really comes in handly at 
times (it often prevents the need for a separate bool to keep track of). 
Only problem is that in Haxe, not only is nullable the default, but it 
doesn't even *have* any non-nullables at all, for any type.


>
> I don't get the diff between currying & partial app. And find this feature 
> much complication for close to uselessness.
>

I'm not certain either, but I *think* partial application is just like 
currying except there's some sort of arbitrary limitaion on what 
combination(s) of paramaters you can choose to specify or not specify. And 
that limitation is based purely on what order the function defines its 
parameters. So basically, my understanding is that partial application is an 
arbitrarily-gimped currying.


>>
>> A class or interface satisfies zero or more interfaces
>>
>> shared class Character(Natural utf16)
>>      extends Object()
>>      satisfies Ordinal&  Comparable<Character>  {
>>          ...
>> }
>>
>> The syntax X&Y represents the intersection of two types. The syntax X|Y 
>> represents the union of two types.
>
> Too bad, they got it wrong, like D. Should instead rip Go interfaces, 
> which are structural & implicite, while still fully compile-time 
> type-safe:
>
>     struct File inStream {
>         ...
>         void write (string s) {...};
>     }
>     ...
>     interface Writer {
>         void write (string s);
>     }
> File is *also* a Writer, thus one can call the following on a specimen of 
> File:
>     void formatWrite (Writer w, string s, string format) {...}
>
> More generally, any type can satisfy any number of interfaces, wherever 
> and whenever they are defined (eg years after, in user code). The 
> obligation of explicitely declaring interface satisfaction is both useless 
> and blocking.
>
> Free interfaces even provide some kind of simple generics for free (like 
> in above example). And there is no need for
>      ... if (is(...))
> or
>      ... if (isWriter!T)
>

I think Go's implicit interfaces are horrible. It's literally nothing more 
than duck-typing at compile time (ie, static duck-typing) and fully inherits 
duck-typing's downfalls (notably that it's sloppy and conflates 
name/signature with semantics - which is an entirely false connection). Of 
course, I guess this argument doesn't hold if you're a duck-typing fan ;)


> Too bad its base for imrovement is Java (there is no way to get light & 
> flexible coding from there, you'd have to change everything ;-),

Yup. This is one of the reasons I don't buy the claims of "Java's fast now, 
really!". In fact, the article I'm [trying to] write for the article 
competition relates to this. Basically, code can't be fast *and* flexible 
*and* maintable without real metaprogramming (and class-based generics don't 
count), and Java AFAIK just doesn't have metaprogramming. Although I suppose 
you might be able to hack it by using a pre-processor, but pre-processors 
have their downsides. And even if you did use one, Java's requirement that 
every aggregate type be a class can be a real hinderance. Of course, the 
JVM's advanced class/object optimizations may be able to help - but only to 
a point, and you still can't reliably prevent situations that would hinder 
the JVM's ability to do the necessary optimizations.