a)
struct 'U { cdr: 'U , lst :list U}
struct 'T : const 'U
union list 'U {
cons data: 'U
nil
}
union ro_list 'T {
cons data: 'T
nil
}
maybe with a constraint ...
union list 'T where :'T const {
cons { car: 'T; cdr: list 'T; }
nil
}
b) An immutable generic list of *mutable* objects
union list 'T {
const cons { car: 'T; cdr: list 'T; }
const nil
}
or if the type system is smart enough this would be nice.
const union list 'T {
cons { car: 'T; cdr: list 'T; }
nil
}
Its more intuitive and easier on arrays ( even though the concurrency is
not) or tress with nodes that use next . Self referencing generics often
( always ?) feel wrong ...and the code can be hard to understand
espeically when you add an order and some constraints or interfaces.
"But this is good. You're all at least beginning to see why dealing with
mutability is one confusing headache after another for the programmer. "
Its not just the implementation but the specification thats at issue ,
what is desired is normally not specified to such a level , even for
concurrent code its just a concurrent list but how is not specified ..
Even worse you normally create your nodes in an array of some sort ( due
to higher perfromance from locality and to avoid repeateded new / malloc
which may not even be available ) with another list having the available
slots , gettiing that working together concurrently is harder...
How often do you want shallow and not deep and you cant get write access
to the tree ? There are cases but its pretty rare and in those cases if you
have encapsulation you could do manual readonly .. maybe default const to
deep and have a different mechanism for shallow. What sort of optomization
can you make use of it is just shallow ?
For local references and parameters you default the reference/ptr to
immutable . So you have the mutable keyword and that pulls them from the
const logic.
Ben
On Fri, Aug 9, 2013 at 10:20 PM, Alex Rozenshteyn <[email protected]>wrote:
> I hope this isn't too much of a tangent, but I wonder how D's choices
> fall: http://dlang.org/const3.html
>
> It has a deep const view and deep immutability (no shallow notion for
> either), almost no inference, and it permits casting away the invariants
> but claims undefined behavior in those cases and could (probably) disallow
> them.
>
>
> On Fri, Aug 9, 2013 at 12:54 AM, Jonathan S. Shapiro <[email protected]>wrote:
>
>> On Thu, Aug 8, 2013 at 5:05 PM, David Jeske <[email protected]> wrote:
>>
>>> I'm not going to use the LISP-esq cons, because I reject the notion that
>>> this solution is a material product of the cell type declarations.
>>>
>>
>> Unfortunately, it *is* a product of how the container data structure is
>> implemented. By "whistling away" the container data structure, you
>> eliminated much of the point I was trying to make.
>>
>> Please bear with me and do it with a LISP-style list first. There's a
>> method to my madness. Also, please do NOT mix up the meanings of const and
>> deep const. They are very different things, and if you to swap all the
>> terminology around on the fly we'll *never* keep the conversation
>> straight. Please resist the temptation to do that, even if chopping off all
>> of your fingers is what it takes to discipline yourself. It's *that*
>> important
>> in these kinds of conversations.
>>
>> I'm also going to demonstrate const/readonly only, since immutability is
>>> a product of there being only const/readonly references alive.
>>>
>>> A generic list of readonly objects
>>>>
>>>
>>> var alist = new List<const Foo>(); // const means deep-const
>>> var alist = (List<const Foo>) new List<Foo>(); // this cast should be
>>> possible
>>> var alist = (List<Foo>) new List<const Foo>(); // I'm okay if this
>>> cast is possible
>>>
>>
>> So going through these:
>>
>> var alist = new List<deep const Foo>()
>>
>> is fine, though it isn't at *all* obvious that parametrics and
>> mutability typing interact favorably.
>>
>> var alist = (List<deep const Foo>) new List<Foo>()
>>
>> is *not* obviously okay, unless you are appealing to a linear typing
>> intuition. In abstract, I agree that we would *like* this to be okay,
>> but it's not clear that the subtyping relation you are tacitly relying on
>> is a valid subtyping relation. Certainly it's a complicated relation that
>> needs careful soundness analysis before we can take it for granted.
>>
>> The last one is just not OK at all. I understand that you personally
>> would tolerate it, but it defeats the entire purpose of access restriction
>> typing, and it defeats soundness in the type system. Please desist on this.
>> readonly/immutable is *not* advisory in this discussion.
>>
>>
>>
>>> "const Foo" means all fields and returned values from methods are also
>>> const, and methods which modify Foo or any data reached from Foo can't be
>>> called since they would require a non-const "this" parameter. The latter is
>>> more useful with const-inference, so we don't have to manually decorate
>>> methods with const.. though we could.
>>>
>>
>> Wow. That's not at *all* obvious from a type system point of view. If
>> you require this, it's nearly certain that the subtyping relation you
>> appealed to above does not hold.
>>
>>
>>>
>>> A readonly generic list of mutable objects
>>>>
>>>
>>> One method is not to use const at all for this, as in...
>>>
>>> ICollectionReadonly<Foo> alist = existingList.asReadOnly();
>>>
>>
>> Yes, but that defeats the point of the exercise, and there actually *was* a
>> point to the exercise as requested...
>>
>>
>>
>> shap
>>
>> _______________________________________________
>> bitc-dev mailing list
>> [email protected]
>> http://www.coyotos.org/mailman/listinfo/bitc-dev
>>
>>
>
>
> --
> Alex R
>
> _______________________________________________
> bitc-dev mailing list
> [email protected]
> http://www.coyotos.org/mailman/listinfo/bitc-dev
>
>
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
