So where are we currently.
I'd vote for Denys approach, mostly because I find the explanation more
appealing, and, as far as I understand, it lacks one minor problem.
But on the other hand, the difference is rather small, so the question
is: Has Kevin a problem with Denys' solution (which is almost Peteer's
und Kevin's solution)?
I think as it comes to explanation in general, both are fine.
Please, this is my opinion. Whatever you think of it, I ask you to
respect it.
Christian
"Denys Duchier" <Denys.Duchier@ps.uni-sb.de> wrote in message
news:<is4rgs54pv.fsf@elk.ps.uni-sb.de>...
> While the discussion was often heated, on the whole it proved quite
> helpful in helping me attune my perceptions of the issues and clarify
> my own thinking on their resolution. I'd particularly like to thank
> Peter and Kevin for putting up with my especially strong-minded style
> of debate (:-).
>
> I believe that, with everybody's help, I have arrived at a simple,
> coherent, and backward compatible proposal. My proposal is a
> conservative extension of the current state of affairs in Mozart.
> Despite Kevin's disheartened reaction, my proposal is also a
> conservative extension of the last P&K proposal, except in a very
> small point of syntax.
>
> The only real point where we depart is one of philosophy: the P&K
> proposal is predicated on the opposition state vs. non-state, while
> mine is founded on the notion of mapping.
>
> 1. CURRENT SITUATION
>
> Mozart supports the abstract notion of "mappings", i.e. partial
> functions from features to values: records, dictionaries, arrays,
> chunks, objects, extensions. Some mappings are mutable, others
> not. The abstract notion of mappings is supported, first through
> polymorphic primitive procedures:
>
> {HasFeature E1 E2 ?B}
> {CondSelect E1 E2 E3 ?V}
>
> second, through polymorphic syntax to read and update mappings:
>
> E1.E2 reads as "the value at feature E2 of E1"
> E1.E2 := E3 reads as "the value at feature E2 of E1
becomes E3"
>
> an attempt to update a mapping dynamically raises an exception if
> the mapping is not mutable. "mapping" polymorphism has proven to
> be extremely useful.
>
> 2. WISHES
>
> * the proposal should be a "conservative" extension.
>
> * attributes currently use @ and <- syntax for access and update:
> it is suggested that they should instead use @ and :=
>
> * cells do not have nice syntax for access and update: it is
> suggested to extend @ and := syntax for this purpose as above
>
> * := should support atomic exchange
>
> * while the "current situation" allows to write code that is
> polymorphic in the choice of mapping, it is not possible to write
> a unary "increment" procedure, where the argument can either be a
> cell or represent the value that a mapping takes at particular
> feature.
>
> 3. PROPOSAL
>
> I define a "ref" to be either an attribute, a cell, or a pair M#F
> of a mapping and a feature. The @ and := are extended as follows
> to work on "ref"s:
>
> @E1 "the value at ref E1"
> @E1 := E2 "the value at ref E1 becomes E2"
> OLD=(@E1 := E2) atomic exchange
>
> The syntax is so chosen that (1) it does not overlap with the
> existing syntax for "mappings", (2) it has a uniform "linguistic"
> reading regardless of whether the expression appears to the left of
> := or not. Note that the notion of "ref" gives us "ref
> polymorphism" in addition to the "mapping polymorphism" we already
> had.
>
> Further, since we wish a conservative extension, we retain:
>
> E1.E2
> E1.E2 := E2
>
> but supplement them with atomic exchange:
>
> OLD=(E1.E2 := E2)
>
> 4. WORK PACKETS
>
> * extend @E to work on refs (attributes, cells, and pairs M#F)
> * implement @E1:=E2 for refs
> * implement atomic exchange OLD=(@E1:=E2) and OLD=(E1.E2:=E3)
> * provide static analysis for the efficient compilation of these
> syntactic extensions (in particular, attribute access and update
> must continue to compile to the same efficient code)
>
> DIFFICULTY ESTIMATION:
>
> No change is required to the parser. A small extension is required
> to the unfolder. New primitives are required (already implemented
> by Kevin, I believe). The only challenging part is the "static
> analysis" and code specialization support.
>
> 5. SEMANTICS
>
> The style of semantics presented here proceeds primarily from the
> stipulation of axiomatic invariants.
>
> A "mapping" is a partial function from features to values. The
> latter can also be regarded as a set of (feature,value) pairs.
> I'll define datatypes by their "semantic profile": for example
> whether the mapping may be modified or not. The domain of a
> mapping is also called its "arity".
>
> I'll consider the following semantics "traits":
>
> * structural or token equality
> * constant or mutable mapping
> * constant or mutable arity
>
> A general principle is that a mutable mapping must have token
> equality.
>
> * Record : a constant mapping with structural equality
> * Chunk : a constant mapping with token equality
> * Dictionary: a mutable mapping
> * Array : a mutable mapping with constant arity. Furthermore,
> the arity is an interval of integers
>
> I propose now an account of cells and, more generaly "references",
> which is more economical than in my earlier message since it no
> longer requires a new primitive type with token equality.
>
> Instead, it admits "opacity" as another semantic trait. For
> example, a chunk is opaque: you cannot obtain its arity. A
> reference is a chunk with arity {MAPPING,FEATURE} where both are
> private names.
>
> A cell is a reference over {(MAPPING,A),(FEATURE,1)} where A is an
> array of arity {1}.
>
> A "reference description" is a pair M#F of a mapping M and a
> feature F. We make the following 2 stipulations:
>
> (Stipulation 1)
> the features MAPPING and FEATURE are private to the
> implementation. Thus the user can never create references
> except through implementation supplied constructors.
>
> (Stipulation 2)
> every primitive that is defined on "references" also accepts
> "reference descriptions" instead.
>
> An advantage of these 2 stipulations is that the implementation
> does not actually need to be modified to handle "references".
> Instead it needs simply deal with cells (as it currently must) and
> additionally with "reference descriptions" (the proposed
> extension).
>
> The semantics of @ and := on references is defined in terms of the
> underlying MAPPING and FEATURE. Here is the specification using
> intuitive notation, not formally pinned down:
>
> @(Chunk<MAPPING:M FEATURE:F>) ===> M.F
> @(Chunk<MAPPING:M FEATURE:F>) := E ===> M.F := E
>
> The behavior with respect to "reference descriptions" is as if a
> reference constructor was applied, i.e:
>
> @(M#F) ===> M.F
> @(M#F) := E ===> M.F := E
>
> Cheers,
>
> --
> Dr. Denys Duchier Denys.Duchier@ps.uni-sb.de
> Forschungsbereich Programmiersysteme (Programming Systems Lab)
> Universitaet des Saarlandes, Geb. 45 http://www.ps.uni-sb.de/~duchier
> Postfach 15 11 50 Phone: +49 681 302 5618
> 66041 Saarbruecken, Germany Fax: +49 681 302 5615
>
> -
> 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/.