[antlr-interest] draft Mantra language proposal

Martin Probst mail at martin-probst.com
Wed Mar 29 00:58:39 PST 2006


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