Attila Szegedi wrote: > That's actually a very promising direction to go in -- there's a bunch > of bytecode-level optimizations that apply across the board for all > (or at least, most) dynamic languages. I'm not referring only to > calling Java from a dynalang, but rather to optimizing the bytecode > produced from a dynalang source code; inferring types (even > speculatively) within methods, having multiple type-optimized versions > of methods when they can be invoked with arguments of different types, > etc. It almost sounds as if it would make sense to come up with a > common framework for such optimizations; using a higher-level > "dynamic" intermediate bytecode format that all dynalang compilers > would compile to, and then having a single dynamic bytecode to JVM > bytecode optimizing compiler ticking underneath them all. (I believe > one of your goals with this list was to actually gather people to > identify such common components and establish a cooperative for > creating a single good implementation for them).
Yes, I've started to lean toward the notion that designing a meta-bytecode layer that's "JVM bytecode ++" would be a more realistic target for many language developers to work toward than what the DLR folks have been aiming for. Put simply, I still believe that coming up with an "abstract semantic tree" that would ever be general enough to support "all" dynamic languages is impossible without making it so finely-chopped and disconnected that it's impossible to realistically optimize. But I digress. I'm getting more to the point where just emitting bytecode is like a second language. I've debated writing portions of JRuby in a Ruby-based bytecode DSL of mine, just so I'd have that bare-metal control over it without all the JVM noise: static_method(:main, Void::TYPE, String[]) do aload 0 ldc_int 0 aaload invokestatic this, :foo, [this, String] invokevirtual this, :getList, ArrayList aprintln returnvoid end And at some level my little "duby" language is really just layering the prettiness of Ruby's syntax directly on top of JVM bytecode, with pluggable type inference and compilation layers to allow compile-time magic. So with what we've done with JRuby and what I'm trying to do with Duby I've come to the realization that we could build bytecode-level libraries or APIs that can cater to both while taking into consideration the vagaries of running well on the JVM and supporting new MLVMish features as they come along. I'm also more and more of the opinion that language design up to the level of emitting bytecode is a very personal experience. Every language designer is going to have quirks and features they want to represent in new and peculiar ways...and though we can come up with useful utility libraries we might all share, trying to form a common runtime all languages can use seems like a wild goose chase, especially in light of so many existing languages and so many wildly different language implementers. But where we have commonality is at the "metal", when we need to make the language fit into the JVM and execute well. This is where we all share most of our common challenges, and I think it's here we can get the most out of sharing efforts. - Charlie --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
