I don't know if this will turn out to go anywhere, but we're still
trying to deal with some weird corners in the BitC type system
concerning MUTABLE, and we're still trying to work through a sensible
meaning for CONST.
Concerning mutability, the variant that we are considering at the moment
is:
An aggregate value is mutable exactly if it is mutable at all
shallow constituent fields (this definition applies recursively).
The programmer is free to write mutable explicitly in this case,
but it will always be inferred if not written.
Otherwise, MUTABLE remains a type constructor in much the way that
it is today.
Concerning CONST, the proposal under consideration is that CONST is a
meta-constructor having the property that
(const T) => T for all scalar types
(forall (RefType 'a)
(const 'a)) => 'a
(const (mutable T)) => (const T)
(const T) on any aggregate type returns a new type T1 in which every
constituent field type FT in T is rewritten to (const FT) in T1.
That is: (const T) strips mutability on an aggregate up to the ref
boundary.
What we are struggling with here is trying to satisfy two simultaneous
objectives:
1. We don't want to encourage too much mutability, but
2. We don't want to end up with nonsense like:
an aggregate that is mutable at all fields can remain
immutable as an aggregate.
There may be an inference completeness challenge with CONST. Swaroop is
looking at that now.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
