[antlr-interest] draft Mantra language proposal
Martin Probst
mail at martin-probst.com
Wed Mar 29 00:58:39 PST 2006
Hi,
to begin with: did you look at some of the other languages? There are
quite some that might solve your issues without having to introduce a
new language. E.g. Groovy, JRuby and Jython on the dynamic side, or
Scala and Nice for static languages. I think all of them provide
closures, function pointers, built in types and the casting thing. Scala
and Nice also have a lot of really interesting functional featuers.
Some longer comments:
* Overly intrusive casting
I don't quite get what you want to do there. From the example you give
it looks as if objects and be auto-cast into subtypes, ie if A extends
B, than you can do "A a = b". I think that is an important feature of a
statically typed OOP programming language. The feature is that the
language gives errors on certain conditions that are with almost
absolute certainty programming errors or design errors. I concurr that
there (almost) should not be a cast statement, but without any automatic
casting ;-). And for casting out of structures you have Java 5 generics.
* Fixing main() declaration
It's kind of annoying, though in every app you develop it happens
exactly once ... are you going to allow function declarations in that
anonymous file without a class? How are you going to identify the
program to run (if you don't have the class name)?
* Closures, function pointers
That's certainly nice. Are you going to have static typing on closures
and function pointers?
* Built in list, hash
That's really nice, too. Always been a pain in Java.
* Properties
I really don't know what people have about this, but maybe it's just me.
And some quick comments:
* a.b.c is ambiguous; use package::class.member - I think that is
a non issue, I've never heard of anyone running into that as a
problem, and if so, it's easily fixed
* CLASSPATH for dev and deploy can be different; result of
compilation should be a jar - you mean "should be a *single*
jar"? I'm not sure if that is something you really want - think
of web containers a la tomcat, layered class loaders, common
(shared) libraries etc. If you duplicate the same libraries in
every jar of every web app you have you'll get an insane memory
usage
* exception "throw or catch contract" is annoying; remove contract
(I might be wrong about this) - I certainly think you are ;-)
* mutable strings; I do not like that the strings and StringBuffer
are different. - this may be a major performance issue, no? Plus
if you add more functional language stuff and especially with
closures, you should probably endorse immutable values, no?
More information about the antlr-interest
mailing list