myWishList

the fanatic has returned! 8-) 
 
my final WishList for Nice x where x >= 1: 
[disclaimer: I don't think any of the following ideas
is new. I have browsed the Wiki once or twice, there
is so much to learn. some of my wishes are precisely
what Nice fights against! this is just to let you guys
know that there are people out there looking forward
to the official release of Nice. these recurring
themes only go to emphasize the importance and the
hunger for them.] 
 
visibility modifiers (classification: plausible,
priority: medium, difficulty: medium) { 
possible scopes: public | package | module | private 
 
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. 
 
package: 
self-evident. no modifiers needed. 
 
module: 
it is nice to see that multiple classes and interfaces
can be defined and implemented in the same Nice file.
it will be just superb if a Nice file acts as a module
as well, preserving the integrity of a set of related
things. it is nice to be able to have the code
distributed among multiple files, but at the same
time, I want to see intimately entangled things all at
once. 
 
private: 
accessible only to those defined within the curly
braces surrounding it, not even to other
implementations of the same class with other
(abstract) interfaces. 
 
I am leaving out the 'protected' scope here. I hope I
will be able to convince you why. 
} 
 
nice documentation (classification: eccentric,
priority: medium, difficulty: low) { 
why would anybody write a comment other than for
documentation purposes? why should there be three
different forms of commenting? I would like to abolish
the Java document style altogether. /* genuine
comments */ will be discarded by the compiler, but
nice documentation, preceding a method or a field,
should look just like 
// @returns the square of an integer 
// x @is the integer to be squared 
int square(int x) = x * x; 
 
of course, you cannot have formal documentation inside
a method declaration, so comment lines do no harm
there. 
} 
 
static import (classification: obvious, priority:
high, difficulty: low) { 
import static my.Constants; 
lets you use all the static methods and fields without
question. 
} 
 
abstract interfaces (classification: disastrous,
priority: medium, difficulty: high) { 
I think, along with multiple dispatches, abstract
interfaces are what make Nice worth learning. having a
functional background, you guys probably feel more at
ease with declarations like: 
Object last(Vector v) = v.elementAt(v.size() - 1); 
 
but I don't. I worked in Java all my life. in my
humble opinion, if you want to add a method to an
existing class, do it via an abstract interface.
moreover, I see no semantic difference between an
ordinary interface and an abstract one. the very
distinction undermines the true value of abstract
interfaces. try this instead: 
interface MonsterWithATail { 
// @returns whether the collection is empty 
boolean isEmpty(); 
 
// @returns the last element of the collection 
Object last() requires !isEmpty(); 
} 
 
java.util.Vector implements MonsterWithATail { 
/* isEmpty() is already implemented... phew! */ 
 
last() = elementAt(size() - 1); 
} 
 
and no method should appear outside such clearly
defined boundaries. public interfaces still are, of
course, just Java interfaces. but this means you will
have to abandon the custom constructor syntax, and I
guess I am more than alright with that. it seems to me
that sacrificing the flexibility Nice offers right now
is too precious to give up and this is, I assure you,
the only thing I am asking for which goes directly
against the principles of Nice. still, think it over,
will you? 
} 
 
match (classification: plausible, priority: medium,
difficulty, medium) { 
does nice have a switch keyword? if so, drop it,
replacing it with the match keyword (personally, I
think the keyword break should only mean breaking out
of a loop). 
match(optionalString, ignoreCase) { 
(null, _) -> throw new Exception("you gave me nothing,
nothing I say!"); 
("nice", _) || ("Nice", false) -> return true; 
(_, _) -> return false; 
} 
 
or, 
match(given) { 
this || this.father() || this.mother() -> return this;

Person p, p.getAge() != -1 && this.getAge() != -1 -> {

if(p.getAge() < this.getAge()) 
return p; 
return this; 
} 
Person p, this == p.father() || this == p.mother() ->
return p; 
Person p -> throw new Exception("no way to tell who's
younger"); 
_ -> throw new Exception("it's not even a person you
are talking about!"); 
} 
} 
 
value dispatch (classification: eccentric, priority:
low, difficulty: low) { 
I hate value dispatching. in Haskell, things are
different, and basically as Nice does not support
pattern matching, I think the match keyword should be
good enough for all practical purposes. 
/* what the hell is this? reminds me of the horrible C
days! */ 
String accordingToKeats(boolean what); 
/* so Java un-like */ 
accordingToKeats(true) = "beautiful!"; 
accordingToKeats(false) = "ugly!"; 
 
/* so nice ;) */ 
String accordingToKeats(boolean what) { 
match(what) { 
true -> return "beautiful!"; 
false -> return "ugly!"; 
} 
} 
 
/* even nicer, but looks exactly like Scala (blush!)
*/ 
String accordingToKeats(boolean what) = match(what) { 
true -> "beautiful!"; 
false -> "ugly!"; 
} 
 
but of course, you guys will cherish the idea that you
can add values later on. I don't. honestly, as you can
already see, modularity means something entirely
different to me, and I like the way Java does it. not
to say I don't like Nice, of course... otherwise why
would I be here?  
} 
 
tail recursion (classification: plausible, priority:
medium, difficulty: low) { 
does Nice support tail recursions? I mean, does it
replace them with equivalent while loops? it's a
trivial matter of course, nevertheless it promotes
functional style. 
} 
 
union and singleton (classification: ambitious,
priority: low, difficulty: low) { 
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? as the traditional implementation of data
structures in Java use null values and we don't like
the idea, it seems natural that this appeals to our
sense of beauty: 
final class Leaf<T> { 
T value; 
} 
 
final class UnaryNode<T> { 
T -> T operator; 
Tree only; 
} 
 
final class BinaryNode<T> { 
(T, T) -> T operator; 
Tree left; 
Tree right; 
} 
 
union Tree<T> (Leaf<T>, UnaryNode<T>, BinaryNode<T>) {

T evaluate(Leaf<T> l) = value; 
T evaluate(UnaryNode<T> u) = (u.operator)(u.only); 
T evaluate(BinaryNode<T> b) = (b.operator)(b.left,
b.right); 
} 
 
I hope the recurring type parameters can be omitted
safely. the key point is a strict set of options, so
exact types can easily be brought into the picture.
if, somehow, we can provide a simple way to construct
singleton classes, enums become superfluous. 
singleton Empty { } 
final class Cons<T> {  
T head; 
List<T> tail; 
} 
 
union List<T> (Empty, Cons<T>) { 
size(Empty) = 0; 
size(Cons<T> c) = 1 + size(c.tail); 
} 
 
or, 
singleton True { } 
singleton False { } 
/* value dispatch? I think not! */ 
union Boolean(True, False) { 
not(True) = False; 
not(False) = True; 
} 
 
... and the like. seems coherent to me! strictly
speaking, for singleton classes, the ambiguity between
the class and the object belonging to the class should
not bother us, basically this is what makes it a
singleton! I can think of two different ways to
overcome this, one is to treat the name as a type name
and use getInstance() to get the instance, the other
is to pretend it's the name of the object but then we
cannot use the instanceof operator on it. but who the
hell needs the instanceof operator when writing in
Nice? 
} 
 
get/set (classification: trivial, priority: low,
difficulty: low) { 
here's the deal: if a field is really really a
secret... we should declare it private with no get
method. if we want the others to have full right on
it, we just refrain from giving it a visibility
modifier. now, that's not hard to do, is it? if we
want Java programs to have access to it, we keep our
cool and provide public get/set methods. a smart
enough IDE can do that for us in a matter of a
keystroke. if both of them are trivial declare it
public for crying out loud. 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, so there is no point
having it auto-generated! it would be nice to set its
access to half-public, so to speak, that is, no value
can be assigned from the outside, but the field is
still accessible. the perfect word would have been
'protected', but unfortunately it has a different
annotation to the Java programmer. I propose
'untouchable'! or more practically, 'sheltered'. I
would not like the word 'readonly'.. simply because
it's not a word. while encapsulation is achieved, our
class will contain one less superfluous method. 
} 
 
IDE (classification: plausible, priority: high,
difficulty: high) { 
how hard can it be? must be easier than doing it in
Java, I imagine, because we have so many more gadgets
under our sleeves! I think the best way to popularize
a language is to give it an overwhelmingly and
deceivingly friendly IDE. of course, the most wanted
feature will be a pop-up list of methods with floating
documentation every time I press a dot, and something
similar when I press an angle left bracket, left
parentheses, comma, or type an arrow or any of
'throws', 'extends', 'implements' and the like.
automatic generation of blank implementations of the
methods required by the interfaces would be nice too.
I won't ask for refactoring at this moment, because it
needs more investigation. running on a virtual machine
will require some time starting up, it would be nice
to have native implementations for just one or two
platforms, too. a GUI designer is welcome, but not at
all necessary. however, writing it up together, the
nice community can put the language to test in a
foreign situation. new ideas could crop up. 
} 
 
immutable (classification: eccentric, priority: low,
difficulty: medium) { 
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. of course, the value of this
feature lies in its semantics, rather than what can be
done with it. I think it will be awesome if the
methods appearing in the 'requires' or 'ensures'
clauses are required to be immutable. 
} 
 
keywords (classification: eccentric, priority: low,
difficulty: low) { 
this shouldn't be on even a wish list. there should
have been something like a fantasy list. the point is,
all the keywords in Java (and Nice) are whole words,
apart from: int, char, enum, var, const... could you
add the whole words to the keyword list, meaning the
exact same thing? could you? please? on the other
hand, instanceof, public-read, private-write are
two-word words. I didn't know about the public-read
keyword when I was writing the get/set part, if it
exists, and means what I think it does, I still prefer
'sheltered' over it. about instanceof, can we come up
with a single word alternative? it's just my taste,
that's all. the language is still young... why should
it carry the old baggage? 
} 
 
lexer, parser and compiler (classification: ambitious,
priority: medium, difficulty: medium) { 
that Nice is an open source language means it has got
nothing to hide. I propose the complete distribution
includes, as a library, Nice itself. the harder part
of this proposition is that the different layers
should be completely isolated, providing interfaces to
extend the rules, but the objective is not really to
make Nice fully customizable. it is customizable
enough, in my humble opinion. what this really
provides the programmer with is a sensible parser and
evaluator of expressions. writing an interactive
thingy will be a trivial matter for anyone interested.
a functional view on the Java reflection mechanism is
not something to be taken lightly. interesting side
effects include the ease of creating IDEs and code
analyzers for the language. if not for anything else,
do it for the sake of anti-capitalism! 
} 
 
inheritance (classification: insane, priority: low,
difficulty: undetermined) { 
what is it good for, the 'protected' keyword? it does
not protect anything, it leaves them wide open! in
general, I don't like the idea that my data is going
to be changed without my consent. in a sense, the 'is
a' relationship does not make sense to me. it should
be a 'conforms to' relationship only. interfaces do
that. when I have an object at hand, all I care about
is what operations I can perform on them. it does not
matter to me whether or not it actually has the same
content or not. besides, object oriented programming
is all about overriding those methods without changing
the look of it. for backwards compatibility, let there
be an 'extends' keyword, but this time meaning a 'has
a' relationship while providing the same interface by
implementing the base class as if it was an interface.
the default implementation of the methods just map to
the base class instance it has. overriding is just not
doing so. super call is a call to the base instance at
hand. I don't think performance is an issue. this
practically makes classes and interfaces equivalent.
you functional people should definitely see that. it's
polymorphism which is important in the end. 
}

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


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