Paralysis of analysis -- the value/ref dilemma

[spir]

On Wed, 15 Dec 2010 11:57:32 -0600
Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:

> On 12/15/10 11:05 AM, spir wrote:
> > What I'm trying to fight is beeing forced to implement semantics
> > values as concrete ref elements. This is very bad, a kind of
> > conceptual distortion (the author of XL calls this semantic mismatch)
> > that leads to much confusion.
> [snip example]
> 
> > Conceptually, we absolutely need both.
> > Again the ref/value semantic duality is independant from data types.
> > If the language provides one kind only, we have to hack, to cheat
> > with it.
> 
> Both are good. The question is which should be the "default" one and 
> what should be the "other" one.
> 
> Your example is from a class of examples that basically say: a mutable 
> reference object in a struct with value semantics is trouble. That is:
> 
> struct Widget // value type
> {
>      ...
>      Array!Color colorMap; // oops, undue aliasing
> }
> 
> That is correct. There are two solutions I envision:

I agree this is also an issue, but this is not the one I had in mind (sorry, for unclear expression).

> 1. Define a Value wrapper in std.container or std.typecons:
> 
> struct Widget // value type
> {
>      ...
>      Value!(Array!Color) colorMap; // clones upon copying
> }
> 
> 2. Define this(this)
> 
> struct Widget // value type
> {
>      ...
>      Array!Color colorMap; // manually cloned upon copying
>      this(this) {
>          colorMap = colorMap.clone;
>      }
> }
> 
> Note that if Widget is a class there is no such problem. The entire 
> issue applies to designing value types.

Actually, that is not what I meant. The actual "nature" (class/struct) of Widget is not the problem I tried to point. Rather to have colorMap's type defined as a class when its meaning (in the model) is of plain value (often to avoid useless copy); or conversely (eg to avoid cost of instanciation on the heap).
Ideally, I would like to have ref vs value distinction orthogonal to the whole type system, meaning "entity with identity" vs "plain data". For this, the language must
(1) properly cope with implemention issues (read: code efficiency),
(2) provide a "ref-ing" syntax similar to "pointing".
I won't dream of the latter, but I guess the first feature can well be done in D. In requires the compiler detecting when a value parameter is not touched in a func body, then passing it by ref behind the stage. This would allow defining conceptual values as instances of value types without fearing inefficiency.
For the converse issue, I have no idea.

> > [...] 
> I don't understand this part.

Not that important [a bit off-topic].

Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com