Dear all,
please allow me to add my two cents to the discussion on whether we can
change the . or not (hey that rhymes!).
In contrast to Denys, I vote for yes here. I have a similar code base
that I maintain to that of Denys, but I like the proposal so much that
I'd go for it. This I say with being absolutely clear that I myself have
to rewrite all of the internal Mozart libraries, I think nobody can be
asked to do that. I am also clear about the fact that this will be very
hard work.
And not having it documented is also a strong argument for me to be able
to change things.
Christian
"Christian Schulte" <schulte@imit.kth.se> wrote in message
news:<ac30fk$ipk$1@grizzly.ps.uni-sb.de>...
> Dear all,
>
> after some discussion Seif and Christian came up with a third model
> which is rather a refinement of what Kevin proposed. The refinement
> has been driven by catering both for easy explanation and easy
> implementation.
>
> The motivation is to base everything on cells and make the well known
> slogan "arrays are tuples of cells" come true.
>
> In the following we are going to describe the proposal in three steps:
> the first step just explains the model, the second explains a naive
> implementation, and the final step describes how the compiler can
> optimize away any overhead.
>
> We restrict our discussion in the following just to dictionaries,
> arrays are of course alike. (D is a dictionary, I is some field of
> it).
>
> Step One: Model
>
> --------------------
>
> The basic and only notion we are dealing with are cells.
>
> Operations on a cell C are access, assign, and exchange (let's forget
> about exchange for the moment). As proposed syntax we have
>
> @C (access)
>
> C := ... (assign, which is also exchange in value position)
>
> The basic idea then is that our model (you know that model) describes
> that a dictionary is a mapping of indices to cells. So the access D.I
> returns a cell. In order to access or to assign the value of that
> cell, the aforementioned operations on cells are used.
>
> This is all what needs to be said on the level of the model. What this
> model achieves is complete equivalence between cells, arrays,
> dictionaries, tuples of cells, record of cells (and also object
> attributes).
>
> The advantage is obvious: no new concept or datatype such as location.
> Just cells.
>
>
>
> Step Two: Naive Implementation
>
> The implementation provides two versions of a cell, one is the native
> cell and is what is already available in Oz to date.
>
> D.I returns a cell that is implemented as a pair of the dictionary D
> and the index I.
>
> Access and assign operations then dispatch on the type of cell.
>
> The advantage here is that the implementation will be fairly simple
> and local as no new datatype needs to be introduced.
>
> Note that the obvious idea would likely be implementing a cell
> obtained by D.I by somehow pointing inside the dictionary. This is
> impossible because it is incompatible with garbage collection (believe
> me (who is Christian)).
>
> Step Three:
>
> The optimization of access and assign now are straightforward, the
> basic point is that cell creation is just avoided when @ immediately
> precedes D.I (this is as Kevin said). Assignment is the same.
>
>
>
> Now an immediate consequnece of this model is that cells obtained by
> D.I can be passed as values and assigned later, which is not possible
> currently.
>
> We feel that this model is simple, does the job, easy to explain and
> generalizes the current state.
>
> Any comments?
>
> From rainy Stockholm
>
> Seif & Christian
>
>
> --
> Christian Schulte, IMIT - KTH, http://www.it.kth.se/~schulte/
>
>
>
> -
> Please send submissions to hackers@mozart-oz.org
> and administriva mail to hackers-request@mozart-oz.org.
> The Mozart Oz web site is at http://www.mozart-oz.org/.
-
Please send submissions to hackers@mozart-oz.org
and administriva mail to hackers-request@mozart-oz.org.
The Mozart Oz web site is at http://www.mozart-oz.org/.