Uuups, not so speedy: Thought about distribution?
The first step anyway will be to rewrite all library code to not use .
for Arrays, Dictionaries any longer.
So do you have an implementation plan? When I go off implementing
something I typically try to put things into different stages and order
them as to get all the dependencies right. Then I typically have some
other people to check that this is feasible. Might be an idea.
CS
"Kevin Glynn" <glynn@info.ucl.ac.be> wrote in message
news:<15594.873.357774.240697@gargle.gargle.HOWL>...
>
>
> We are happy with this proposal, and support adding a polymorphic
> mapping operator _->_ for accessing values stored in both stateful and
> non-stateful structures.
>
> The idea to extend the runtime representation of cells to be also able
> to store dict/key pairs is v. good and will much simplify the
> implementation.
>
> We believe that the only built-in operations required on runtime cells
> are creation, access, assign, exchange, equality, and garbage
> collection. Any more places I need to check?
>
> I would like to restart the implementation as soon as I can, so I hope
> we can reach agreement quickly.
>
> Thanks for everybodys help,
>
> Kevin
>
>
>
> Seif Haridi writes:
> > 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
> > -
> > 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/.
-
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/.