> Hej Guys,
>
> just a minor comment about (A) and (C). While I understand that this
> maintenance release is worth having, in the mid run I'd rather like to see
> us devoting our effort to the development branch again.
>
> I for myself decided that I will not spend any time on the fixes branch as
> it is the past and my current amount of time available does not allow me to
> spend it on the past. On top of that, I fear serious divergence. On the
> other hand, I'd like to contribute a couple of things (fixes and
> considerable improvements for propagators) and I feel unconvinced to do it
> as the development branch seems to not get a fair chance of usage any time
> soon...
>
> What I'd propose is start collecting development projects from everybody for
> a new line of releases based on the development branch. By development
> projects I mean that everybody writes a couple lines what and why something
> needs to be done. Based on this we can settle a nice package of features and
> a timeline for getting the development branch stable and worthwhile for
> release.
At UCL, we are planning to do the following three development projects.
Now is as good a time as any to bring them out in the open:
1. Fix by-need synchronization and read-only variables. The current version
of ByNeed is broken, in our view, since it is not declarative. We have a
design of a declarative version (i.e., that results in a sublanguage of Oz
that
is concurrent, lazy, and declarative) that we planned to present to you all.
We already have a proposed semantics: it is given in the book by Seif &
myself, in Section 13.1.12 (ByNeed) and Section 13.2 (declarative
concurrency). We have a proof outline that the semantics of Section 13.1.12
is indeed declarative according to the definition of Section 13.2. Finally,
we have thought about the distribution protocol that it would need, and it
is a trivial extension to the current distributed binding protocol.
2. Add a construct to the language for dynamic scoping. We have noticed
the absence of dynamic scoping in several independent places. There are
many ways to do dynamic scoping. We have discussed several of them
internally at UCL and we would like to bring this discussion in the open
to find what is the 'right' concept. This would replace SiteProperty by
the 'right' thing.
3. Fix the object system. There are several small problems with it now:
a. For various reasons, it should be possible to set 'self' to a specific
value when an object is created (for example, to do delegation in a nice
way). This is a small thing, but since it is a language change it needs
discussion.
b. The 'object feature' concept is broken. Why should an object have
encapsulated stateful attributes and public stateless features? In our
view, the existing features should be removed and replaced by
encapsulated
stateless features. I.e., remove features and add stateless attributes.
This is important for encapsulation and for distribution (it is important
to know when an object is stateless).
We agree to do the development effort for these at UCL. Some (esp. number 2)
still need a lot of design discussion.
Peter
-
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/.