Quick response on Glen's syntax question, because the rest needs some thought.
On Thu, Aug 8, 2013 at 4:29 PM, Glen Anderson <[email protected]>wrote: > > >> > An immutable generic list of mutable objects > >> > >> cons T { > >> T *readonly car; > >> cons T *readonly cdr > >> }; > > > > > > Rewriting: > > > > union list 'a is > > cons { car: 'a readonly; cdr: list 'a readonly; } > > nil > > Slight tangent into syntax here as I think I'm missing something, this > isn't the translation I'd have come up with. Based on the what I know > of BitC's syntax I'd translate this back to: > > cons T { > readonly T *car, > readonly cons T *cdr > }; > I'm not sure whether this last fragment is meant to be C or BitC. Since you use readonly, I'm assuming BitC, and that leads me to say there are five problems here. First, the '*' is adding a double indirection, which the BitC definition of list 'a doesn't do. If T is a boxed type, the car cell will already end up a pointer. If T is an unboxed type, we end up with a "fat" slot for the car cell. BitC also doesn't use '*' for "pointer to", but that's a minor nit. It was plenty clear what you meant. Second, you're still not addressing the fact that list is a union type, unless what you're trying to write here is just the "cons" sub-portion of the union declaration. So the type of the cdr field isn't right here. In your version, it is not possible for cdr to be NIL/NULL. Third, the generic parameter is written with a type variable, so 'T rather than T throughout. Fourth, in BitC the type goes after the identifier, as in Pascal. So taking these four issues into account, the thing you wrote above would turn into: union list 'T { cons { car: readonly 'T; cdr: readonly list 'T; } nil } But your main point - and the fifth issue in your version - is the positioning of "readonly". In the C version: T * const car; the const means that the pointer living in the car cell cannot be mutated. It does NOT mean that T is itself an immutable thing. When I first wrote about the fact that C# didn't allow readonly in all of the necessary positions, I introduced the possibility that readonly might appear before the identifier in the same way that it can in C. So that would give T readonly car except that BitC does types in Pascal fashion, which would give us: car: T readonly and when I looked at that it seemed god-awful to have a keyword way over on the right talking about the field name way over on the left. That leaves me with a version that is readable but somewhat awful: readonly car: T as opposed to readonly car : readonly T which would be an immutable field referencing a constant object. > While I agree with this, it strikes me as another example of how > adding const/readonly type annotation can seriously mess with > intuition. > Yes. That was part of the point I was trying to illustrate. > Even if/once the technical challenges for const/readonly types are > solved, getting programmers to reason about them effectively is going > to be tough. > In fact, it will be even tougher than it is in C, because C doesn't have parametrics. I haven't looked at how this is handled in C++ template expansion, but in C++, "const" isn't part of type; it's a modifier. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
