View mode: basic / threaded / horizontal-split · Log in · Help
September 17, 2012
Re: References in D
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.
September 17, 2012
Re: References in D
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
September 17, 2012
Re: References in D
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
September 17, 2012
Re: References in D
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
September 17, 2012
Re: References in D
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
September 17, 2012
Re: References in D
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
September 17, 2012
Re: References in D
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
September 17, 2012
Re: References in D
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
September 17, 2012
Re: References in D
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.
September 17, 2012
Re: References in D
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
2 3 4 5 6 7 8 9 10
Top | Discussion index | About this forum | D home