Re: myWishList

> of course, I still need to convince you that a syntax
> change would be nice. it certainly is not *required*,
> everything is going so fine without it. if I turn the
> compiler switch off, I loose communication with the
> other packages. tuples, lambdas, kinds... why would I
> bother programming in Nice if I don't use them? other
> Nice packages simply cannot be on par with Java
> classes. 

This switch would still let you use those features internally in the package. 
Now do you want to have public features that are visible from other Nice 
packages, but not from Java packages? That seems like a strange requirement: 
public means visible to the whole world, so as the designer of a library you 
cannot know if it will be used from Java, from Nice, from 
SomeLanguageCompiling ToTheJVM, ... So either you decide to be friendly to all 
languages and refrain from using some features in the whole public interface, 
either you don't.

Maybe what you have in mind is a library designed to be used from Java, but 
with "friend" packages written in Nice? This could be addressed by the more 
flexible visibility system I mentionned in the previous thread.

> should the compiler add runtime checks? does
> it now? that's simply aweful. suppose someone from
> Java 1.1 passes you a vector of strings. well, you
> *expect* a vector of strings from him/her. but s/he is
> free to send you anything s/he wants. will your
> compiler check every member of the list? or will you
> let your program though the dreaded
> ClassCastException? if that same method is called from
> a Nice program, you are sure you don't need to be
> careful, that's the whole point, isn't it?

Exactly. Nice helps you write code with less bugs. But if the bug is in the 
Java code, there is not much Nice can do about it.

> just another thought: about.. cast(), I don't think
> any non-external method should need it. do you?

It should be extremely rare, and you are encouraged to think hard about an 
alternative way to do things to avoid it. At worst, it is cleaner to use 
'assert x instance Foo;' than a plain cast. Actually, there should not be much 
more reasons to use cast in methods interfacing with Java code. By using 
retyping, you can work around the lack of precision of Java types.

>>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
> 
> sure I can. but is it hard to implement?

_Self_ tail calls could be handled relatively easily, but it's still some work 
complexifying the compiler. If somebody wants to do it, I won't object and I 
can help.

The general case is quite hard to implement in a bytecode compiler. It's 
possible, and it has been done using tricks that result in *slower* method calls.

> I don't agree
> with your 'should be handled' part. it's an
> optimization that any functional language requires,
> and more that Java requires it. if you can provide it,
> why not?

We can provide it, but only for simple cases, really. A JVM can do it in all 
cases, it would benefit all programs (without recompilation, and for all 
languages compiling to bytecodes). So, in an ideal world, it *should* be 
handled by the JVM. Actually some do implement it (if I remember well, some 
versions of IBM's JVM). If somebody has precise information about which ones 
do it would be interesting.

> I am totally confused here. there is no way to stop
> unwanted subclassing in Java as far as I know. I
> foolishly tried 'abstract final' once, to mean that
> only the inner classes of this class can extend it.

You can prevent subclassing outside the package by making all constructors 
non-public.

> I am not sure if I can follow you. Rohan's
> re-statement  of immutability seems to be the one I am
> proposing. the principle interest here is a greater
> depth of security. if it is hard, forget it.

Isn't what you are proposing similar to those:

http://david.tribble.com/text/javaconst.html
http://bugs.sun.com/bugdatabase/view_bug.do;:YfiG?bug_id=4211070


> easier constructor of a nice IDE... ;)

So as I said the compiler is already modularized to some extent, and I'm 
willing to adapt it to specific requirements.

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