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/.