On Jul 15, 4:00 am, Dibyendu Majumdar <[email protected]> wrote: > On Jul 14, 10:52 am, Shantanu Kumar <[email protected]> wrote: > > > 1. Data should be immutable by default. I like Clojure's > > implementation of immutability and atom/ref (STM). Clojure's transient > > are useful too. > > Hmmm ... need to think about this. >
You may consider using this: http://github.com/krukow/clj-ds I blogged about data immutability in Java here (just in case): http://charsequence.blogspot.com/2010/02/data-immutability-in-java.html > > 2. Implementation inheritance should be disabled. No abstract classes > > either. :) > > Not practical because inheritance is needed sometimes. Even Go > supports it though it is not advertised. > But I agree inheritance is generally to be avoided. My thinking is > that by default classes will be final unless you explicitly allow > inheritance. Need to think about the syntax for this. > Sadly, you are right. Even making classes final by default has a catch -- tools that instrument classes to override methods transparently may have issues (Hibernate ORM, AOP tools etc). > > 3. Inter-operable and binary compatible with Java. Should be able to > > call Java code. There should be a mechanism to call from Java. > > Agree. No special mechanism should be required - as the language > should transform to an equivalent Java program. > > > 4. Syntactic sugar for defining and implementing Thin-interfaces > > (interface with just one method signature) - then it looks like a > > closure. > > Not sure what you mean by this; could you give an example. > How to define: public interface :FetchData(args); // notice the colon How to use: doSomething(new :FetchData(args) { // do processing // ... // you can look at loop/recur in Clojure for recursion }) > > 5. Checked exceptions should be regarded like unchecked ones. > > Agree, need some advice on how to do this in a generic way. > Checked exceptions are a Java-compiler-only feature. Once you translate to bytecode you don't necessarily need to catch the exception. > > 6. No "static" blocks of code. > > It would be nice to avoid, but static initialization of modules is > often needed. > When all data is immutable / guarded, is it still needed? The Class.forName("jdbc.driver...") is an odd case. > > 7. No "synchronized" keyword. Language should have better concurrency > > primitives. Queues / message passing (actor/agent model?) may be > > favored. > > Certainly not something as verbose. I am thinking of supporting > explicit locks (mapped to java.util.concurrent.locks). > Why map to something that can be already used as part of Java-interop? > > 8. Should not introduce monkey-patching. But anything like Lisp macros > > would be great. > > Not familiar with this. > > > 9. [Optional feature] Regular expressions at a language level. > > Not a big use case for me ... > > > 10. [Optional feature] Conditions and restarts as in Common > > Lisp:http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-... > > try-catch-finally seems good enough to me. > > Regards > Dibyendu Regards, Shantanu -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
