Re: myWishList

On Fri, 17 Jun 2005, Daniel Bonniot said:
 > If you want close ADT, you should be able to use enums.

Only if the elements have some uniform structure, something not common
to ADTs.

 >> > immutable
 >> 
 >> > the final modifier says the reference cannot change.  but
 >> > immutability means, in addition to that, no action can be taken
 >> > that changes state of the object. it's more than the requirement
 >> > that none of the fields is assigned any new value: their states
 >> > cannot be changed either, and so on.
 >> 
 >> Given that we don't have a monadic (or equivalent) type to track state
 >> in Nice and there's very little likelihood that Java will have one
 >> either this would essentially stop *any* method call on the immutable
 >> field's object or its contained objects, and so on.
 >> 
 >> Adding state mutation tracking sounds hard.

 > I think the idea is that methods could be marked to document if they modify
 > their arguments, similarly to the const keyword in C++.

Immutable parameter references would just be a version of 'let'.  But
immutability in general is either going to have to trust methods do
what they say, or gain mutation tracking system.  Otherwise give up
static knowledge and use runtime checks only.

There's also the choice of external or internal immutability.  By that
I mean whether the aforementioned runtime tests would be

  newA.equals(oldA)

or some assurance that all fields, private included, are ==

 >> > lexer, parser and compiler

 >> completely off topic: the SGLR folk
 >> (http://www.cwi.nl/htbin/sen1/twiki/bin/view/SEN1/SGLR) make
 >> convincing argument that the lexer/parser split is bad.  Having used
 >> it (and contemplated using it for parsing Nice) I agree.

 > Interesting! So that would be an alternative parser? The parser API
 > is already separate from the core compiler, so that should make it
 > easier to implement.  What benefits do you expect?

The immediate benefit is that any context-free grammar is accepted and
there are no shift/reduce errors or the like - it simply produces a
parse tree containing ambiguities and it's up to some later stage to
determine which was the correct parse (though there are limits to the
number of ambiguities it'll allow for a single parse).  This makes it
really easy to extend a grammar, indeed grammars can be composed so,
for example, parts of the Java1.5 grammar
(http://www.stratego-language.org/Stratego/JavaFront) could be
imported for use in the Nice grammar.

There's also quite a few related tools such as tree transformers,
pretty printers, and the like
(http://www.stratego-language.org/Sdf/SdfApplications) but then you'd
be replacing chunks of the compiler itself and there's no
Java-callable version of those tools that I'm aware of.

Interestingly, there are Haskell versions for anyone wanting to follow
in pugs' footsteps (http://www.pugscode.org/)

Rohan



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click