Guys,
could you sum up the proposals together with arguments (of course only
after you believe that the discussion has reached its fixed point). I'd
really love that.
Christian
Kevin Glynn wrote:
>
> Looking at your arguments below I think I can make just as strong
> arguments for a slight variant of my proposal. In this variant
> accessing an element of a dict/array requires the prefix operator @
>
> So to update a dictionary:
>
> D.I := E (as before)
>
> To access an element of a dictionary:
>
> @(D.I) (instead of just D.I)
>
> [Another alternate could be to make @ . a multifix operator for
> dict arrays:
>
> @D.I
> ]
>
> Any use of D.I in any other context would be an error, so that we
> don't expose the fields of the dict/array.
>
> I favour this notation, but discounted it earlier because it wasn't
> backwards compatible. But I now don't think we sould worry so much
> about that. It has the advantage that @ is a visual reminder to the
> programmer/reader that the value we are retrieving the *current* value
> of something that may change.
>
> Now using this proposal:
>
> Denys Duchier writes:
> > glynn@info.ucl.ac.be (Kevin Glynn) writes:
> >
> > > I don't understand why a symmetric notation is any better.
> >
> > Because it captures simply a linguistic generalization. In
> > particular, it is independent of the choice of syntactic expressions
> > which we choose to designate as "locations".
> >
> > First it expresses a meta-syntactic principle: if LOC is a location,
> > then the value bound to this location is obtained by evaluating LOC
> > and it can be updated by LOC:=E
> >
>
> If LOC is a location then LOC is a location. The operator @ returns
> the current contents of LOC.
>
> > Second it expresses a meta-semantic principle: after successful
> > reduction of LOC:=X, evaluating LOC reduces to X.
> >
>
> After successful reduction of LOC := X, evaluating @LOC reduces to X.
>
> > The reason I said that you could not escape the curious interpretation
> > of the left hand-side of := is because of the construction E1.E2:=E3.
> > Now, if I understand correctly, your counter-argument here is that
> > there are 2 constructions: _._:=_ and _:=_. My reply is that if you
> > are willing to entertain these 2 constructions, then you could just as
> > well consider these two: _._:=_ and @_:=_.
> >
>
> I 'suffer' multifix operators, rather than 'entertain' them.
> Particularly when they overlap with another viable meaning.
>
> > The linguistic principle I stated requires no special cases. Should
> > we ever invent new kinds of locations, it would apply to them
> > unchanged. It makes linguistic, cognitive, and didactic sense.
> >
>
> I find our proposal easier to describe than yours. I really don't
> like the fact that the meaning of sub-expressions changes implicitly
> depending on context. (We still do this a bit when we ban D.I in
> contexts other than := and @, I know).
>
> > I understand quite well that it can be frustrating to have one's
> > design rattled by an external opinion, but, hopefully, by working
> > together, we can arrive at a better design for all.
>
> Sorry if I gave that impression, I very much appreciate your comments,
> and ideas. I think we are working together! I don't think these
> syntactic variants make much difference to my implementation.
>
> regards
> Kevin
> -
> 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/.
-- 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/.