Vala could replace C ...

[Reiner Pope]

renoX wrote:
> Reiner Pope Wrote:
> 
>> renoX wrote:
>>> Reiner Pope Wrote:
>>>> kris wrote:
>>>>> http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-programming-with-less-fat 
>>>>>
>>>>>
>>>>> "Vala is still a work in progress, but support for the language is 
>>>>> growing rapidly. Close GObject integration makes Vala an ideal choice 
>>>>> for GNOME development, and the requisite library support is steadily 
>>>>> falling into place. Vala's biggest deficiency right now is the lack of 
>>>>> documentation. In time, Vala could replace C as the principle language 
>>>>> of the GNOME platform."
>>>> Most of the listed features, D has too:
>>>> - Interfaces
>>>> - Properties
>>>> - Signals  (why is this a language feature?)
>>> Maybe to have a better syntax? 
>>>
>>>> - Foreach
>>>> - Lambda expressions
>>>> - Type inference for local variables
>>>> - Generics
>>>> - Non-null types
>>> Are you sure that D has the 'non-null types' feature?
>>> What I understand by 'non-null types' is like in Nice:
>>> having a syntax to declare nullable types, and by default types are not nullable i.e
>>> Type foo = null; is an error (if possible a compile-time error).
>>> Type? foo = null; is ok.
>>> This means that when you have a function f(Type t) you don't need to check in f whether t is null or not, it's already done for you.
>>>
>>> AFAIK D doesn't have this.
>> You should have read what you quoted afterwards  :-)
>>
>>>> I'm not sure how type modules work, but I do know about non-null types, 
>>>> and they would sure be nice in D.
>>>>
>>>>
>>>>    -- Reiner
>> D doesn't have it, but I think they would be nice.
> 
> Ooops, sorry for having misread your post.
> 
> And yes it would be nice but on one hand it's a "specialised" feature, it only works for non-null checks, I've read some article about Haskell which talks about 'type modifiers' where for example you could declare a function to return a type 'Maybe Foo'
> and the typesystem makes you checks whether there is an error or not before being able to use 'Maybe Foo' as 'Foo'..
> So it's more generic, but of course having Type? is a more readable syntax than 'MaybeNull Type'.
> 

I think that's just a feature of pattern matching with algebraic data 
types. (Well, when I say just, I don't mean to demean it, though.) They 
are very interesting, but they can mostly be already emulated in D 
through meta-programming (I've been playing with doing this and it is 
over-all quite promising. For many of the problems I encounter, I think 
"this will be fixed with hygienic macros").

The problem is that it is easy, given a never-null type to make a 
maybe-null type -- you just make an algebraic datatype

      data MaybeNull a = Null | Some a

whereas the situation is much harder the other way around: how do you 
create a never-null type based on a maybe-null type?

We can try to emulate this in future D using static parameters:

struct NeverNull(T)
{
     T impl;
     void opAssign(static T t)
     {
         static assert(t !is null, "Can't assign null to a never-null");
         impl = t;
     }

     T implicitCastTo()
     {
         return impl;
     }
}

This would catch any attempt to write

NeverNull!(int*) = null;

at compile-time (since null is a compile-time constant). However, the 
fundamental problem is that the type system loses information in 
constructors: the result of a constructor is guaranteed to be non-null 
(am I right? or are there GC issues?), yet it is typed as a nullable 
type. So the following *should* be guaranteed to work

NeverNull!(int*) = new int;

yet assigning a nullable to a never-null doesn't typecheck in the 
general case, as it could allow

int* i = null;
NeverNull!(int*) = i;

Without never-null types, I don't think the type system can distinguish 
those two cases.


     -- Reiner