A very fascinating set of considerations. I'll have to read the paper-reference to get up to date. Before I take my hand at a syntax-expression example, I'd like to state some perspective differences:
Note that in most cases, deep const is a lot less useful than you might > think, and what we actually wanted was deep immutable. I don't understand this, since deep-const is strictly a superset of deep-immutable. As you said, if there are only const references, then something is immutable. My primary interest is not immutability, but const API contracts without the code and runtime overhead of making read-only proxy types and implementations. (I want C# readonly to work for non-scalars) I would accept a C/C++ like unenforced-const, as in "please don't edit this because you're probably not supposed to. If I was wrong, you'll need to cast it to explicitly tell the compiler to let you edit it".. And now, on to the spectacle... 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. 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 "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. 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(); Here the list had to already be declared to implement ICollection<T> which was a derivation of ICollectionReadonly<T>. Another method is to use const, and rely on the fact that methods which change the list require a non-const pointer, as in.. var alist = (const ICollection<Foo>)new List<Foo>(); alist.Add(aFoo); // compiler error, because ICollection:Add() requires non-const "this" > An appendable generic list of mutable (or readonly) objects One method is for List to implement ICollection<T> which is a derivation of ICollectionAppend<T> which is a derivation of ICollectionReadonly<T>. var alist = (ICollectionReadonly<Foo>)new List<Foo>(); var alist = (ICollectionReadonly<const Foo>)new List<const Foo>(); ---- In order to take an existing list which is not read-only, and return an efficient read-only or append-only view which is not a proxy (aka, has the same object pointer), we need to solve the trait resolution problem we talked about earlier.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
