Re: Dynamic Language Runtime
Thanks for the lowdown Mark! It's a pity OSA didn't take off - I remember having some success with coding JavaScript, AppleScript, and event tried but failed some python I think all within Rev IDE (back when we had MetaCard), its just that the incentives were not there for the language communities to make them OSA compatible. It seems from what you are saying that this may not be a problem with the DLR / .NET approach? NB - the DLR stand for Docklands Light Railway where I come from :) ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Dynamic Language Runtime
Thanks Mark. In general you seem to be supporting the potential of this path? It seems at this stage more promising than other stabs at this no - say Open Scripting Architecture (OSA), and yes it means a lot more than just a browser plugin - though i guess this would get most peoples attention here? A question about writing a transcript compiler for DLR? What does this involve - starting from scratch in C# or if you were RunRev and already presumably had some code basis for a compiler would you be able to use that directly - I guess not. Secondly if it means starting from scratch would that mean anyone could legally undertake such a thing - that is to write a minimal Transcript compiler for the DLR. Its not something I am picturing doing - but I am curious :) On 09/05/07, Mark Wieder [EMAIL PROTECTED] wrote: David- I was part of a DLR roundtable discussion at CommunityOne day at JavaOne yesterday, so I think I can speak to this from the bleeding edge. A few points to consider: 1. The DLR is alpha. I'm bullish on it, and it's very promising, but there are quite a few rough edges and things that just aren't worked out yet. There's no consensus on threads, for instance. Give it time. 2. The DLR means a lot more than just being able to run something in a browser. It promises cross-language compatibility, the ability to run modules written in one language within the context of another language. 3. There's never been a jit compiler for xtalk. Not that it couldn't be done, but that brings headaches of its own. The whole short path / long path thing, for one, is something that I don't think has ever been considered for xtalk syntax. 4. Peter Fisk's Smalltalk compiler is capable of processing arithmetic expressions. That's still a far cry from a full-blown Smalltalk compiler. I'm reasonably certain that a compiler that would process put 2 + 3 in Transcript wouldn't be that hard to build. But there's a lot more to the infrastructure than that. 5. We can't all be Peter Fisk. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Dynamic Language Runtime
David- Wednesday, May 9, 2007, 8:21:09 AM, you wrote: A question about writing a transcript compiler for DLR? What does this involve - starting from scratch in C# or if you were RunRev and already presumably had some code basis for a compiler would you be able to use that directly - I guess not. Secondly if it means starting from scratch would that mean anyone could legally undertake such a thing - that is to write a minimal Transcript compiler for the DLR. Its not something I am picturing doing - but I am curious :) Well, on one level I think that anyone could start this from scratch. There aren't any legal restrictions that I'm aware of to anyone creating a new xtalk compiler or interpreter or whatever. And if you have something that compiles xtalk down to an intermediate byte-level interpreter the way I'm given to understand the runrev engine now works, then the first task would be to create a code generation engine whose end result would be binary-compatible with the jvm. This is the equivalent of creating a new platform for runrev to run on in addition to the currently-supported platforms, rather like taking on the project of having runrev deploy on a Treo or a Newton or a your platform of choice here. The next task would be to craft a jit compiler to handle the dynamic binding aspect of the dlr. This is by far the harder of the two tasks (not that I want to minimize the difficulty of the first task). It's nothing I'd take on lightly - there are brighter minds than mine hard at work on these things. Jruby is the most promising right now, and the entire Rails framework seems to be working fine, thanks to a *lot* of hard work and the cooperation of the ruby community. Starting to veer off-topic for this list, so I don't want to get in too deep. But if you're seriously interested in working on the dlr, John Rose is the person to be in touch with. And he's actively casting his net for more collaborators. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
