Some really solid arguments there and Mirah looks interesting. As I
realize:
-- Mutable data is fine as long as it is either unsharable or guarded.
-- Rather than letting the user define a new Thin-interface, it makes
more sense to make use of Runnable and Callable interfaces.
val x = runnable /* or callable */ { // so runnable and callable
become keywords
// code here
};
-- Concurrency primitives may best be left away from language.
Libraries can handle that.
Regards,
Shantanu
On Jul 15, 11:23 am, Charles Oliver Nutter <[email protected]>
wrote:
> A bit of musing on which of these features I agree/disagree with and
> what's in Mirah or planned for Mirah...
>
> On Wed, Jul 14, 2010 at 4: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.
>
> I like language-level immutability. I do not like forced "everything
> is immutable", and current VMs/GCs don't appear to either. I think
> there's a happy medium between the two that no current language has
> really found. I've been considering ways to do it in Mirah, and in
> JRuby you can actually extend Clojure::Object instead of regular
> Object and get an immutable instance-variable set.
>
> > 2. Implementation inheritance should be disabled. No abstract classes
> > either. :)
> > 3. Inter-operable and binary compatible with Java. Should be able to
> > call Java code. There should be a mechanism to call from Java.
> > 4. Syntactic sugar for defining and implementing Thin-interfaces
> > (interface with just one method signature) - then it looks like a
> > closure.
>
> Mirah does this now:
>
> Thread.new { ... this becomes a Runnable ... }
> Arrays.sort(someArray) {|a,b| ...this becomes a Comparator... }
>
> > 5. Checked exceptions should be regarded like unchecked ones.
>
> A trivial feature to add, but it makes interop trickier (if you don't
> declare throws, Java *can't* catch).
>
> > 6. No "static" blocks of code.
>
> In Mirah these look like class-level methods, but follow the same
> lifecycle as static methods. Is there really a right way to do this?
> Even Scala's "objects" are just static singletons.
>
> > 7. No "synchronized" keyword. Language should have better concurrency
> > primitives. Queues / message passing (actor/agent model?) may be
> > favored.
>
> Hard to do without introducing a library, perhaps? The biggest problem
> I've seen with languages that incorporate actors out of the box is
> that they get it wrong...repeatedly...and developers are basically
> left to implement actors themselves anyway. The more libraries your
> language depends on, the more chances you have to pick the wrong
> libraries.
>
> > 8. Should not introduce monkey-patching. But anything like Lisp macros
> > would be great.
>
> Mirah has compiler macros; we're trying to expand the possibilities of
> the language that way, rather than by adding standard libraries.
>
> > 9. [Optional feature] Regular expressions at a language level.
>
> Mirah's parser is based on Ruby, where regexp are a syntactic feature.
> Currently it just does a Pattern.compile every time that syntax is
> encountered, though.
>
> > 10. [Optional feature] Conditions and restarts as in Common Lisp:
> >http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-...
>
> Probably need continuations for this. Maybe could simulate it with coroutines.
>
> - Charlie
--
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.
