Are there any projects to create an implementation of EcmaScript/JavaScript that will run on top of parrot? -- David "liorean" Andersson <uri:http://liorean.web-graphics.com/>
On Sat, 27 Nov 2004 21:43:01 +0100, liorean <lior...@gmail.com> wrote: > Are there any projects to create an implementation of > EcmaScript/JavaScript that will run on top of parrot?
I believe not. That's really something that should get done, though...
On Sat, 27 Nov 2004 22:48:42 +0100, liorean <lior...@gmail.com> wrote: > CLR, JVM and C/C++ implementations exists. As parrot is supposed to be > better for dynamic languages, I guess EcmaScript 3.0 would fit right > in with parrot.
It should. EcmaScript is also a relatively small language, which would work strongly in its advantage...
[snip]
> I'd love to contribute. Could one write an initial compiler in > JavaScript, compile from SEE or SpiderMonkey and then run the compiler > on that implementation?
What the compiler would do is to transform JS code into PIR ... you most likely could do that in any language, so another JS implementation wouldn't be impossible.
On Sat, 27 Nov 2004 21:11:07 +0000, Herbert Snorrason
<metha...@gmail.com> wrote: > On Sat, 27 Nov 2004 21:43:01 +0100, liorean <lior...@gmail.com> wrote: > > Are there any projects to create an implementation of EcmaScript/JavaScript that will run on top of parrot? > I believe not. That's really something that should get done, though...
CLR, JVM and C/C++ implementations exists. As parrot is supposed to be better for dynamic languages, I guess EcmaScript 3.0 would fit right in with parrot.
I have only the smallest knowledge of other languages (have made some tries at Scheme and Ruby, but I don't really feel comfortable with them), but I have used JavaScript since first introduced in nn2 and I'd love to contribute. Could one write an initial compiler in JavaScript, compile from SEE or SpiderMonkey and then run the compiler on that implementation? -- David "liorean" Andersson <uri:http://liorean.web-graphics.com/>
>On Sat, 27 Nov 2004 21:11:07 +0000, Herbert Snorrason ><metha...@gmail.com> wrote: >> On Sat, 27 Nov 2004 21:43:01 +0100, liorean <lior...@gmail.com> wrote: >> > Are there any projects to create an implementation of >>EcmaScript/JavaScript that will run on top of parrot? >> I believe not. That's really something that should get done, though...
>CLR, JVM and C/C++ implementations exists. As parrot is supposed to be >better for dynamic languages, I guess EcmaScript 3.0 would fit right >in with parrot.
>I have only the smallest knowledge of other languages (have made some >tries at Scheme and Ruby, but I don't really feel comfortable with >them), but I have used JavaScript since first introduced in nn2 and >I'd love to contribute. Could one write an initial compiler in >JavaScript, compile from SEE or SpiderMonkey and then run the compiler >on that implementation?
Absolutely. Compilers do *not* have to be integrated in with parrot -- my current work project uses Parrot as its back end, but the compiler's written in perl as a standalone program. Works just fine. (Though a Javascript compiler written in Javascript could bootstrap itself pretty nicely. That'd be cool... :) -- Dan
--------------------------------------it's like this------------------- Dan Sugalski even samurai d...@sidhe.org have teddy bears and even teddy bears get drunk
Dan Sugalski wrote: > At 10:48 PM +0100 11/27/04, liorean wrote:
>> On Sat, 27 Nov 2004 21:11:07 +0000, Herbert Snorrason >> <metha...@gmail.com> wrote:
>>> On Sat, 27 Nov 2004 21:43:01 +0100, liorean <lior...@gmail.com> wrote: >>> > Are there any projects to create an implementation of >>> EcmaScript/JavaScript that will run on top of parrot? >>> I believe not. That's really something that should get done, though...
>> CLR, JVM and C/C++ implementations exists. As parrot is supposed to be >> better for dynamic languages, I guess EcmaScript 3.0 would fit right >> in with parrot.
>> I have only the smallest knowledge of other languages (have made some >> tries at Scheme and Ruby, but I don't really feel comfortable with >> them), but I have used JavaScript since first introduced in nn2 and >> I'd love to contribute. Could one write an initial compiler in >> JavaScript, compile from SEE or SpiderMonkey and then run the compiler >> on that implementation?
> Absolutely. Compilers do *not* have to be integrated in with parrot -- > my current work project uses Parrot as its back end, but the compiler's > written in perl as a standalone program. Works just fine. (Though a > Javascript compiler written in Javascript could bootstrap itself pretty > nicely. That'd be cool... :)
Probably the best base to start with is Rhino, which is a standalone open source JavaScript compiler written in Java - originally done by the JavaScript team at NetScape. This code is quite good. And coincidentally is in the process of absorbing a set of patches to add continuation support.
Overall, JavaScript would be a good match for Parrot. One place where it would significantly diverge at the moment is in the concept of a "class". Objects in JavaScript are little more than bundles of properites, some of which may be functions. And classes are essentially templates for such objects.
Sam Ruby writes: > Overall, JavaScript would be a good match for Parrot. One place where > it would significantly diverge at the moment is in the concept of a > "class". Objects in JavaScript are little more than bundles of > properites, some of which may be functions. And classes are essentially > templates for such objects.
That's why there's the find_method vtable. I don't see how it would be difficult to do in any way.
On Sat, 27 Nov 2004 19:30:20 -0500, Sam Ruby <ru...@intertwingly.net> wrote: > Probably the best base to start with is Rhino, which is a standalone open source JavaScript compiler written in Java - originally done by the JavaScript team at NetScape. This code is quite good. And coincidentally is in the process of absorbing a set of patches to add continuation support.
Actually, I've spent the last couple of hours looking into three implementations: Narcissus, Rhino and SpiderMonkey (and SEE a little, too). I'd say Narcissus seems like a far better starting point for at least two things: First of all, it's a JavaScript in JavaScript implementation. Second, it's by far the easiest to get a grip of. (Probably because of what language it's written in. C and Java contains so much syntactic sugar...) The bad part is that Narcissus is an interpreter and not a bytecode compiler, unlike the other two.
As for continuations, I've known about Cocoon for a while, and their Rhino with proper tail recursion and first class continuations. It's neat, and I'd certainly not go any other way. (Parrot should make this easy, compared to JVM/CLR...)
> Overall, JavaScript would be a good match for Parrot. One place where it would significantly diverge at the moment is in the concept of a "class". Objects in JavaScript are little more than bundles of properites, some of which may be functions. And classes are essentially templates for such objects.
I don't really think it's that strange. Essentially, all objects contain a reference to their prototype. When getting a member of an object, the object will first check it's own members for the corresponding identifier, then ask it's prototype, and so on until the prototype chain is depleted. Setting is always done on the object itself. It's really not so much inheritance as it is conditional runtime delegation. Functions are of course first class and shouldn't differ from any other member - there is no native method/property distinction in JavaScript, even though host object may have such a distinction. The difference between a function and a method is the binding of the this keyword. Privacy is all handled by the closure creation, so that should be a freebie with implementing constructors.
Note that the prototype delegation system could very well exist on an object which inherits properties from a class, if the host allowed it. The systems are orthogonal. But then I expect that to get ugly fast, especdially with a Ruby-like class system... Hopefully LiveConnect can be tweaked so that it can give the same automatic wrapping/unwrapping of parrot native objects as it provides for Rhino and Java natives in JVM. -- David "liorean" Andersson <uri:http://liorean.web-graphics.com/>
> On Sat, 27 Nov 2004 19:30:20 -0500, Sam Ruby <ru...@intertwingly.net> > wrote:
>> Overall, JavaScript would be a good match for Parrot. One place >> where it would significantly diverge at the moment is in the concept >> of a "class". Objects in JavaScript are little more than bundles of >> properites, some of which may be functions. And classes are >> essentially templates for such objects.
> I don't really think it's that strange. Essentially, all objects > contain a reference to their prototype. When getting a member of an > object, the object will first check it's own members for the > corresponding identifier, then ask it's prototype, and so on until the > prototype chain is depleted. Setting is always done on the object > itself. It's really not so much inheritance as it is conditional > runtime delegation. Functions are of course first class and shouldn't > differ from any other member - there is no native method/property > distinction in JavaScript, even though host object may have such a > distinction.
This seems to me to be very much the way Python works as well, though the emphasis is different. (That is, the common case in Python is to define methods per-class rather than per-instance, and in JavaScript it's the opposite. But that's not a technological difference, just a cultural one.) I would think that the implementations would share a lot.
Jeff Clites wrote: > On Nov 27, 2004, at 5:58 PM, liorean wrote:
>> On Sat, 27 Nov 2004 19:30:20 -0500, Sam Ruby <ru...@intertwingly.net> >> wrote:
>>> Overall, JavaScript would be a good match for Parrot. One place >>> where it would significantly diverge at the moment is in the concept >>> of a "class". Objects in JavaScript are little more than bundles of >>> properites, some of which may be functions. And classes are >>> essentially templates for such objects.
>> I don't really think it's that strange. Essentially, all objects >> contain a reference to their prototype. When getting a member of an >> object, the object will first check it's own members for the >> corresponding identifier, then ask it's prototype, and so on until the >> prototype chain is depleted. Setting is always done on the object >> itself. It's really not so much inheritance as it is conditional >> runtime delegation. Functions are of course first class and shouldn't >> differ from any other member - there is no native method/property >> distinction in JavaScript, even though host object may have such a >> distinction.
> This seems to me to be very much the way Python works as well, though > the emphasis is different. (That is, the common case in Python is to > define methods per-class rather than per-instance, and in JavaScript > it's the opposite. But that's not a technological difference, just a > cultural one.) I would think that the implementations would share a lot.
I agree with both of you (and with Luke's observation on the existance of a find_method vtable entry, which I've used to good advantage already inside PyClass.pmc).
What I am finding is that a very different approach is embedded inside object.c and needs to be factored out into what is currently (mis-)named ParrotObject and ParrotClass.
I have ideas on how this should be handled, but my needs are not (yet) urgent, and Dan has expressed an interest in making the change, so I'm willing to wait for a little bit.
On Sat, 27 Nov 2004 21:49:49 -0500, Michael G Schwern <schw...@pobox.com> wrote:
> On Sat, Nov 27, 2004 at 09:58:44PM +0000, Herbert Snorrason wrote: > > It should. EcmaScript is also a relatively small language, which would > > work strongly in its advantage...
> A 188 page language spec is small? ;)
ECMA-262, ECMAScript Language Specification: 172 pages. ECMA-334, C# Language Specification: 448 pages. ISO 1539-1, Fortran Part 1, Base language: 567 pages. ISO 1989, COBOL: 859 pages. ISO 9899, C: 538 pages. ISO 14882, C++: 757 pages.
