Don't take this wrong, I do know that this is a major breakage, and would arm the language if applied in any short term manner. Still, acknowledging error that have been made is usefull.

BTW, I guess Nullable!T could use unions to handle null on reference types without having a separate pointer.

On Monday, September 17, 2012 12:52:52 deadalnix wrote:
> Le 17/09/2012 02:23, Jonathan M Davis a écrit :
> > Regardless, the solution at this point is going to be to add std.typecons.NonNullable. It would be in there already, but the pull request with it needed more work, and it hasn't been resubmitted yet.
> 
> I don't think this is implementable as a lib in a satisfying way.

Then take it up with Walter and Andrei. After a number of discussions on this in the newsgroup (and probably outside it as well), they agreed that it was not worth putting non-nullable references in the language and that a library solution was sufficient.

- Jonathan M Davis

On Monday, September 17, 2012 13:00:15 deadalnix wrote:
> Don't take this wrong, I do know that this is a major breakage, and would arm the language if applied in any short term manner. Still, acknowledging error that have been made is usefull.

Not everyone agrees that an error _was_ made. There's a big difference between acknoweldging that non-nullable references could be useful and agreeing that having nullable references be the default was a bad idea. I very much that it will _ever_ happen that non-nullable references would be the default (certainly, it will _not_ happen in D2), even if they were added.

- Jonathan M Davis

On 9/17/12 6:52 AM, deadalnix wrote:
>> Regardless, the solution at this point is going to be to add
>> std.typecons.NonNullable. It would be in there already, but the pull
>> request
>> with it needed more work, and it hasn't been resubmitted yet.
>>
>
> I don't think this is implementable as a lib in a satisfying way.

It is, but it needs just a bit of language support in constructors. Walter never got around to it.

Andrei

On Mon, 2012-09-17 at 09:12 -0400, Andrei Alexandrescu wrote:
> On 9/17/12 6:52 AM, deadalnix wrote:
> >> Regardless, the solution at this point is going to be to add
> >> std.typecons.NonNullable. It would be in there already, but the pull
> >> request
> >> with it needed more work, and it hasn't been resubmitted yet.
> >>
> >
> > I don't think this is implementable as a lib in a satisfying way.
> 
> It is, but it needs just a bit of language support in constructors. Walter never got around to it.

Somewhat hypocritically as I cannot volunteer myself just now… just because Walter didn't get round to it, doesn't mean it can't be done. People who want the feature should find a way of creating the resource to make it happen. Four ways: volunteer to do the work themselves; club together to raise the cash to contract someone to do the work; get an organization to stump up a person to do the work; get an organization or seven to stump up cash to contract someone to do the work. There is nothing quite like providing a pull request to get things moving ;-)

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 09/17/2012 03:33 AM, Jonathan M Davis wrote:
> On Monday, September 17, 2012 03:27:10 Timon Gehr wrote:
>> On 09/17/2012 02:23 AM, Jonathan M Davis wrote:
>>> ...  That might make sense for an int, since
>>> it can't be null, but pointers and references _can_ be and are in every
>>> type system that I've ever used.
>>>
>>> ...
>>
>> You have claimed multiple times to have used Haskell.
>
> I have, but I've never used pointers in haskell, so if they're non-nullable, I
> wouldn't know about it. I believe that everything in Haskell is an immutable
> value type as far as what I've dealt with goes.
>
> - Jonathan M Davis
>

In effect, everything is a non-null reference to mutable, but as
mutation is constrained rather specifically, it is possible to reason
about the behaviour of Haskell programs on a higher level of
abstraction.

> let fib n = if n<2 then n else fib (n-1) + fib (n-2)
> let x = fib 30
> let y = x
> let z = x
> y
(delay)
832040
> z
(no delay)
832040

On Mon, 2012-09-17 at 15:49 +0200, Timon Gehr wrote:
[…]
> In effect, everything is a non-null reference to mutable, but as mutation is constrained rather specifically, it is possible to reason about the behaviour of Haskell programs on a higher level of abstraction.
> 
>  > let fib n = if n<2 then n else fib (n-1) + fib (n-2)
>  > let x = fib 30
>  > let y = x
>  > let z = x
>  > y
> (delay)
> 832040
>  > z
> (no delay)
> 832040

This is just an artefact of Haskell being a lazy language: x is only evaluated on demand; the lack of delay is due to the fact the value is already computed.

Hopefully no-one actually uses that expression for calculating Fibonacci series for real.

Are you sure the references are to mutable? I had understood Haskell to be a single assignment to immutable values language.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 17-09-2012 15:12, Andrei Alexandrescu wrote:
> On 9/17/12 6:52 AM, deadalnix wrote:
>>> Regardless, the solution at this point is going to be to add
>>> std.typecons.NonNullable. It would be in there already, but the pull
>>> request
>>> with it needed more work, and it hasn't been resubmitted yet.
>>>
>>
>> I don't think this is implementable as a lib in a satisfying way.
>
> It is, but it needs just a bit of language support in constructors.
> Walter never got around to it.
>
> Andrei

What support, exactly?

I mean, we have @disable already.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On 09/17/2012 03:56 PM, Russel Winder wrote:
> On Mon, 2012-09-17 at 15:49 +0200, Timon Gehr wrote:
> […]
>> In effect, everything is a non-null reference to mutable, but as
>> mutation is constrained rather specifically, it is possible to reason
>> about the behaviour of Haskell programs on a higher level of
>> abstraction.
>>
>>   > let fib n = if n<2 then n else fib (n-1) + fib (n-2)
>>   > let x = fib 30
>>   > let y = x
>>   > let z = x
>>   > y
>> (delay)
>> 832040
>>   > z
>> (no delay)
>> 832040
>
> This is just an artefact of Haskell being a lazy language: x is only
> evaluated on demand; the lack of delay is due to the fact the value is
> already computed.
>

The runtime cannot know that the value has already been computed
without keeping state. Identity is important, if I had written
let y = fib 30
let z = fib 30

There would have been a delay two times.

> Hopefully no-one actually uses that expression for calculating Fibonacci
> series for real.
>

This worry actually demonstrates my point. Different representations of
the same value are not equivalent in practice.

> Are you sure the references are to mutable?

An evaluated expression is not the same thing as a non-evaluated
expression. But the same name is used to refer to both in the example,
ergo the reference is to mutable.

> I had understood Haskell to be a single assignment to immutable values language.
>

That is the abstraction it provides. Values do not change, but their
representations have to, because of the evaluation strategy.

On Mon, 17 Sep 2012 16:28:46 +0200, Alex Rønne Petersen <alex@lycus.org> wrote:

> On 17-09-2012 15:12, Andrei Alexandrescu wrote:
>> On 9/17/12 6:52 AM, deadalnix wrote:
>>>> Regardless, the solution at this point is going to be to add
>>>> std.typecons.NonNullable. It would be in there already, but the pull
>>>> request
>>>> with it needed more work, and it hasn't been resubmitted yet.
>>>>
>>>
>>> I don't think this is implementable as a lib in a satisfying way.
>>
>> It is, but it needs just a bit of language support in constructors.
>> Walter never got around to it.
>>
>> Andrei
>
> What support, exactly?
>
> I mean, we have @disable already.

We have the keyword. It's currently horribly broken.


-- 
Simen