Re: Dynamic Language Runtime

2007-05-10 Thread David Bovill

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

2007-05-09 Thread Mark Wieder
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 .

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.



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


Re: Dynamic Language Runtime

2007-05-09 Thread David Bovill

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


Dynamic Language Runtime

2007-05-08 Thread Mark Wieder
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.

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