Re: myWishList

--- Daniel Bonniot <[email protected]> wrote:
> 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.

I guess I completely agree with Rohan here. his
'external' (my 'public') is not the same as the
'public' you are suggesting. I had an initial draft of
the message that included another scope.. the 'nice'
scope! I deleted it afterwards without much thinking,
and I guess that matches Rohan's 'public'. I will go
for Rohan's choice of keywords, 'public' to mean
visible to other packages (in the same jar?),
'external' to mean visible to Java (and thus any other
jars). to Rohan: what do you mean 'external public'?
that's superfluous! don't shorten it to 'extern',
please, I beg you. it would be nice to be able to
declare an 'external' block and define multiple
methods within that, that gives me the Java face of my
package.

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

I am dropping my 'module' scope. the
'external'/'public' distinction is far more important.

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

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

> >  > union and singleton
> > 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.

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.
didn't work as far as I remember. all you can do is to
stop subclassing altogether, using 'final'. that's
somewhat harsh! I guess Rohan meant this: we don't
have 
a way to stop it, if we had, we would have closed
ADTs. in that case, my proposal is precisely to have
it, isn't it? what confuses me is what Daniel said.
what good are enums, every one of them being just
single objects with uniform structure? by now, Java
has them, and I think ADTs are more general and
mingles more with the functional approach than the
enums anyway. it's a beautiful language construct, in
my humble opinion, and it provides you with a way to
control subclassing.

the thing that attracted me most, is that with ADTs in
the form I proposed, you have type-based dispatching
rather than value-based dispatching. that satisfies
both my Java and my Haskell tastes. but more to the
point is: limited subclassing, generality, and a
syntax for singletons. Scala, I think, uses the
keyword 'object' to mean... I am not sure, may be a
collection of static things? what I am proposing is
that there should be only a single instance of the
class for a singleton, and the language should take
that into account and need not name the instance.

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

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.

> >  > lexer, parser and compiler
> 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.

no I don't have any specific needs. I just thought, as
Nice is almost an academic language...

> 
> > completely off topic: the SGLR folk
> 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?
> 

easier constructor of a nice IDE... ;)


__________________________________________________
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