So why did I say *Naively* Understood Terms?
Characterizing this as naive understanding is probably the wrong word. It's
at least clear what "shallow" and "deep" mean, and what "readonly" and
"immutable" mean, so that's progress.
But there is a challenge problem here that looks very much like the "owned
list" discussion. Assume you have shallow, deep, readonly, and immutable,
and assume further that the language lets you write the extended uses of
readonly that I described above. How would you write the types for each of
the following:
A generic list of immutable objects
An immutable generic list of *mutable* objects
An *appendable* generic list of mutable (or immutable) objects
Note that *all* of these are types you especially want to be able to write
in concurrent programs. Also, by "list", here, I mean in the LISP-style
cons-cell form. That's not a great list layout, but it's a simple one, and
it's enough to help you trip over this exercise.
What I'm trying to draw out here is three points:
1. Shallow and deep mutability intuitions are too coarse for a bunch of
cases we care about.
2. Mutability constraints aren't type *modifiers*; they are an integral
part of the type.
3. This *hugely* complicates typing for generics. There wasn't even a
theory of how to handle
that prior to Swaroop's work during the BitC project.
But quite apart from that, I'll be very interested to see what textual
conniptions people come up with for writing those three kinds of lists with
these tools. For the moment, I'm going to withhold the punch line about
this to see what people come up with.
As you make your attempts, be sure to expand the underlying list data
structure to make sure that when the types propagate to the fields of the
cons cell you haven't shot your own foot off along the way...
Have fun
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
