On 5/15/14, 11:03 AM, Walter Bright wrote:
> On 5/15/2014 2:45 AM, Don wrote:
>> An interesting side-effect of the recent addition of @nogc to the
>> language, is
>> that we get this ability back.
>
> I hadn't thought of that. Pretty cool!

Yah, that's unexpected in a nice way. -- Andrei

On 5/15/2014 4:32 PM, Andrei Alexandrescu wrote:
> On 5/15/14, 11:03 AM, Walter Bright wrote:
>> On 5/15/2014 2:45 AM, Don wrote:
>>> An interesting side-effect of the recent addition of @nogc to the
>>> language, is
>>> that we get this ability back.
>>
>> I hadn't thought of that. Pretty cool!
>
> Yah, that's unexpected in a nice way. -- Andrei


Nice to have a positive surprise!

On 5/15/2014 4:00 PM, H. S. Teoh via Digitalmars-d wrote:
> What if the language allowed the user to supply a proof of purity, which
> can be mechanically checked?

I think those sorts of things are PhD research topics. It's a bit beyond the scope of what we're trying to do with D.

Walter Bright:

> I think those sorts of things are PhD research topics. It's a bit beyond the scope of what we're trying to do with D.

Perhaps yes.
Yet, the Whiley language is not PhD-level, and it's inspiring :)

Things like value range propagation show that even rather small amounts of statically known information can give back plenty of value to D!

Bye,
bearophile

On 5/15/14, 2:52 PM, Timon Gehr wrote:
> On 05/15/2014 08:03 PM, Andrei Alexandrescu wrote:
>>>>
>>>> Purity of allocation is frequently assumed by functional languages
>>>
>>> Examples?
>>
>> cons 1 2 is equal to cons 1 2
>> ...
>
> I don't see anything whose specification would need to mention
> 'allocation'.

That's the point. There's no specification of allocation - the evaluator may create two lists or reuse the same, and it's all transparent.

>>>> because without it it would be difficult to get much work done.
>>>
>>> Why?
>>
>> It's rather obvious. You've got to have the ability to create new values
>> in a pure functional programming language.
>
> This kind of operational reasoning is not essential. Of course, in
> practice you want to evaluate expressions, but the resulting programs
> are of the same kind as those of a non-pure language, and can do the
> same kind of operations. There is not really a distinction to be made at
> that level of abstraction.

I'm afraid I got lost here.


Andrei

On 5/15/2014 5:20 PM, bearophile wrote:
> Walter Bright:
>
>> I think those sorts of things are PhD research topics. It's a bit beyond the
>> scope of what we're trying to do with D.
>
> Perhaps yes.
> Yet, the Whiley language is not PhD-level, and it's inspiring :)
>
> Things like value range propagation show that even rather small amounts of
> statically known information can give back plenty of value to D!

Yes, the VRP has been a nice win for D. No other language does it.

On Thursday, 15 May 2014 at 13:42:58 UTC, Steven Schveighoffer wrote:
> In any case, the alternative is to have D pure functions avoid using pointers. It's as drastic as that.

You need:

1. references with value semantics.

2. "non pure exceptions" that cannot be caught within a pure chain, but can be caught outside

Besides that I think programmer provided guarantees for referential transparency are valuable for C/ASM and for non-pure to pure conversion using the exception in point 2.

On Friday, 16 May 2014 at 00:27:34 UTC, Andrei Alexandrescu wrote:
> On 5/15/14, 2:52 PM, Timon Gehr wrote:
>> On 05/15/2014 08:03 PM, Andrei Alexandrescu wrote:
>>>>>
>>>>> Purity of allocation is frequently assumed by functional languages
>>>>
>>>> Examples?
>>>
>>> cons 1 2 is equal to cons 1 2
>>> ...
>>
>> I don't see anything whose specification would need to mention
>> 'allocation'.
>
> That's the point. There's no specification of allocation - the evaluator may create two lists or reuse the same, and it's all transparent.
>
>>>>> because without it it would be difficult to get much work done.
>>>>
>>>> Why?
>>>
>>> It's rather obvious. You've got to have the ability to create new values
>>> in a pure functional programming language.
>>
>> This kind of operational reasoning is not essential. Of course, in
>> practice you want to evaluate expressions, but the resulting programs
>> are of the same kind as those of a non-pure language, and can do the
>> same kind of operations. There is not really a distinction to be made at
>> that level of abstraction.
>
> I'm afraid I got lost here.

I believe Timon's point is that allocation is an implementation detail, just like the existence of registers, memory caches, and the stack. Those things need not exist to perform the computation and as a result there is no need to assume anything about their purity (as far as the language is concerned, they don't exist).

D dropped the ball (perhaps) by making memory allocation real. If 'new' was just defined to create a new object without specifying (directly or indirectly) that it lived in memory and had an address that could be compared then the allocation of memory would be an implementation detail invisible to the language, and that would allow "true" purity, and the optimisation opportunities that come with it.

On Thursday, 15 May 2014 at 21:48:16 UTC, Timon Gehr wrote:
>> The term "pure function" is only needed in a non-functional language.
>> Applicative/functional languages only have mathematical functions, no
>> need for the term "pure" there.
>
> In discussions about e.g. Haskell, it is often used to denote an expression of a specific form inside a `stateful' DSL. E.g. if "η" is the unit of some monad, then (η v) is sometimes called a "pure value", while values of other forms are not called pure.

Yes, from haskell.org:

<<While programs may describe impure effects and actions outside Haskell, they can still be combined and processed ("assembled") purely, inside Haskell, creating a pure Haskell value - a computation action description that describes an impure calculation. That is how Monads in Haskell separate between the pure and the impure.>>

So, I think my statement holds.

>
> Yes, the VRP has been a nice win for D. No other language does it.

I don't know why you keep saying things like that, you don't know all the languages out there. Nimrod does it too fwiw...