OK. Let me back up on my previous. I'm sticking with the vector problem/issue here, and I'll come back to the broader issue in a moment.
Step 1: Observe that an array (at least in BitC) is either mutable at all positions or immutable at all positions. The types "array(mutable char)" and "mutable array(char )" are equivalent, and the hypothetical type "mutable array(immutable char)" is nonsense. Step 2: The type: mutable ref(immutable array(char)) is perfectly sensible (don't bug me about the parens here - I hate them too, but let's stay on track for the moment). Step 3: From a syntactic perspective, the type: mutable vector(char) is taken to mean "mutable reference to VectorPayload(char)", and in the absence of further information derived from inference, will eventually be resolved as: mutable vector(immutable char) So the problem when writing: mutable char[] is that we are mingling a prefix operator with a postfix operator, in such a way that the binding is ambiguous (i.e. to the human). Someone suggested that "mutable" should bind tightly, in which case this will get interpreted as ref VectorPayload(mutable char) but in that case we'll eventually see something like: mutable(mutable char[]) My personal take is that this is okay - outer mutability is easy to infer and generally not confusing when inferred. Ultimately, though, the source of confusion here is that the postfix [] notation is actually responsible for two constructions: it introduces both the "ref" and the "VectorPayload" constructions. Now the reason this is sufficiently expressive (ignoring the precedence confusion) is what I said in Step 1 about arrays: if the payload type of VectorPayload is mutable, then the sequence is mutable, and we still have enough syntax (given enough parens) to separately express the mutability of the reference. The reason I failed to notice the ambiguity in the S-expression syntax is that it simply wasn't present. The precedence issue per se will get resolved. The real question is what the relationship is between [im]mutability and types. I'm actually starting to think that I have the beginnings of a handle on that, but it needs a somewhat extended note, and I'm too sleepy at the moment to get that note written correctly. So I'm off for a ~1hr nap, and then I'll give it a try. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
