Re: myWishList

Hi Imam

On Wed, 15 Jun 2005, Imam Tashdid ul Alam said:
 > I have browsed the Wiki once or twice,

given the scope of these wishes you might want to add some of them to
said wiki for ease of future discussions

----------------------------------------

 > visibility modifiers

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

Tuples are really arrays - the compiler could add runtime type checks.
Functions can also be done but it'd be ugly from the Java side so
probably not worthwhile.  Parameterised types can also have runtime
type checks added.  I can't see any harm in retaining contracts.
 
 > of course, you cannot have formal documentation inside a method
 > declaration, so comment lines do no harm there.

Unless you're doing literate source code but that's a larger change.

----------------------------------------
 
 > abstract interfaces

 > Object last(Vector v) = v.elementAt(v.size() - 1);

Well, it avoids having to come up with some meaningful name for the
interface.
 
 > moreover, I see no semantic difference between an ordinary
 > interface and an abstract one.

abstract interfaces (or kinds) are (currently?) a weaker statement
than ordinary interfaces in that they are 'provides' vs. 'is a',
ie. you can *only* call methods on a class implementing a kind.

----------------------------------------

 > match

 > does nice have a switch keyword?

No, and the canonical answer is that this is provided by
multi-dispatch.  That would be a nicer solution if local functions
could be multi-dispatched.

----------------------------------------

 > value dispatch

 > I hate value dispatching.

So don't use it

I liked it more the closer to Haskell pattern matching it got.  In any
case the current implementation is really only adding an infinite
number of commonly recognised Platonic entities to the set of classes
considered for dispatch, in much the same way that singleton classes
are available for dispatch.

 > but of course, you guys will cherish the idea that you can add
 > values later on. I don't.

Closed vs. open enumerations is a slightly different topic.  I think
Java provides both.

----------------------------------------

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

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

----------------------------------------

 > get/set

 > within Nice, a curious situation arises sometimes, where the get
 > method is trivial (how can a get method be non-trivial, I wonder),
 > the set method is not

Which situation is that?

----------------------------------------

 > IDE

 > I think the best way to popularize a language is to give it an
 > overwhelmingly and deceivingly friendly IDE.

but... but... we already have emacs  8*)

[Sorry, nothing constructive to add here]

----------------------------------------

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

----------------------------------------

 > 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

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.

----------------------------------------

 > inheritance

 > what is it good for, the 'protected' keyword? it does not protect
 > anything, it leaves them wide open!

Nice doesn't (won't?) have protected.

cheers
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