Re: myWishList

Hi,

Thanks for this interesting list of ideas, and to Rohan for his thorough 
answer. I'll first answer Rohan's message when I have something to add, then 
maybe the other one is something is left out. Please let me know if I'm 
leaving some aspect unaswered.

>  > public:
>  > I want the word 'public' to mean 'for the people out there'. that
>  > is, public things will be in direct communication with Java. public
>  > methods can only be defined within public classes and
>  > interfaces. they will abhor the nice features, like taking
>  > functions, tuples, type parameterized objects as parameters or
>  > returning them. they should have multiple dispatches though, but no
>  > contracts.
> 
> What is this "Java" you talk of?
> 
> Seriously, won't Nice methods want to call methods in different
> packages?  That's 'public'.  Ensuring that a method, whether public or
> package, can be easily used called from Java is still a good idea.
> I'd attach an additional qualifier to the method definition, eg.
> 
>   public external int foo(int bar)

I'm not even convinced we need to have special handling for methods designed 
to be called from Java. The trend has been to compile Nice methods in such a 
way as to make it natural to call them from Java code. As long as it does not 
impose drawbacks for pure Nice code, there is no reason not to do so (it's 
just some effort to put in the compiler).

If you just want to check that some features (tuples, anonymous functions, 
...) are not used in the public signature of a package, that could be checked 
by a simple tool or compiler switch, but I don't think it should be reflected 
in the syntax of the language.


>  > tail recursion
> 
>  > does Nice support tail recursions?
> 
> Not last I looked.  Nice still seems in the "build functionality"
> phase rather than the "make it fast, make it not run out of stack"
> phase.

I also think that tail call elimination is an optimization that can and should 
be handled by the runtime, for instance the JIT compiler. See this RFE at 
Sun's (you can vote for the feature): 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4726340

>  > union and singleton
> 
>  > what is the preferred way to do algebraic types?
>  > extending a base abstract class and using multiple
>  > dispatches? but that does not ensure that my object at
>  > hand will have any one of a fixed set of types, does
>  > it?
> 
> Yes.
> 
> Correct.
> 
> It's an open "algebraic data type".  If there was some way to stop
> unwanted subclassing, eg. only subclassing within the current package,
> then it would allow closed ADTs.

If you want close ADT, you should be able to use enums.

>  > 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++.

>  > lexer, parser and compiler
> 
>  > I propose the complete distribution includes, as a library, Nice
>  > itself.
> 
> I believe that the compiler is callable but not its constituents.
> 
>  > the harder part of this proposition is that the different layers
>  > should be completely isolated

I agree with this goal, and there is already some support. The package 
nice.tools.compiler, for instance, offers an interface to parse programs and 
resolve the names. Many of the tools use parts of the compiler as a library, 
see for instance nicedoc.

There is indeed work to do to improve the design in this respect. If you have 
specific needs, let us know.

> 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?

Daniel


-------------------------------------------------------
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