Unofficial wish list status.(Jul 2008)

[Fawzi Mohamed]

On 2008-07-23 18:14:53 +0200, Sean Kelly <sean at invisibleduck.org> said:

> Fawzi Mohamed wrote:
>>  From another post of Walter:
>>> 4. Invariant data can be placed in hardware protected readonly memory, 
>>> such as ROM.
>> 
>> I thin the invariant should not necessarily allow that.
> 
> I think the salient point is that invariant data /can/ be placed in 
> ROM, not that it has to.  In fact, only some invariant data can be 
> placed in ROM--that data which is known at compile-time.  const data in 
> D 1.0 works this way.

It depends on what the purpose of invariant is.

If the purpose of invariant is to enable good support for functional 
style, and avoid concurrency problems then I think that an invariant 
that guarantees that 4 is never automatically enforced would be better 
(that or the infamous mutable/unpaintable keyword, or (but more 
difficult to do well at the first attempt, instead of letting this be a 
library implementable feature) language given thunks).

The thing is that as there are lazy functions (and those are present in 
D) there are also lazy datastructures.

Lazy datastructures can have pieces that are not yet computed, so they 
cannot be invariantW.

A simple example is a linked list (it could be also a tree, or other 
structures), if it is lazy it can be produced "as needed" and if the 
root is not needed consumes little memory.

These are powerful features of functional languages that would not be 
part of D functional core.

Fawzi