EcmaScript
Liorean
EcmaScript/JavaScript that will run on top of parrot?
--
David "liorean" Andersson
<uri:http://liorean.web-graphics.com/>
Herbert Snorrason
> 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...
--
Schwäche zeigen heißt verlieren;
härte heißt regieren.
- "Glas und Tränen", Megaherz
Herbert Snorrason
> 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.
Liorean
<meth...@gmail.com> wrote:
> On Sat, 27 Nov 2004 21:43:01 +0100, liorean <lio...@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?
Dan Sugalski
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
Sam Ruby
> At 10:48 PM +0100 11/27/04, liorean wrote:
>
>> On Sat, 27 Nov 2004 21:11:07 +0000, Herbert Snorrason
>> <meth...@gmail.com> wrote:
>>
>>> On Sat, 27 Nov 2004 21:43:01 +0100, liorean <lio...@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
Luke Palmer
> 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.
Luke
Liorean
> 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.
Jeff Clites
> 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
Sam Ruby
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.
- Sam Ruby
Herbert Snorrason
> 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...
>
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.
Yes, it is. :)
James Mastros
> 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... :)
Though integration with the parrot compiler system would be very useful,
both for writing browsers and similar in parrot, and for implementing
javascript's eval() builtin.
That could well come quite a bit later, though -- after you can
bootstrap yourself into PIR, for example. (Either with yourself, or
compiling whatever other language you're written in into PBC.)
-=- James Mastros,
theorbtwo
Liorean
> Dan Sugalski wrote:
> > 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... :)
> Though integration with the parrot compiler system would be very useful, both for writing browsers and similar in parrot, and for implementing javascript's eval() builtin.
We'll see how I'll do it eventually. Right now I've just begun working
on a lexer and parser. It would be easy to do if I dropped regular
expressions support, but the regular expressions syntax makes the
lexer dependent upon the parser. Though I haven't looked into them
yet, but I suspect the E4X additions also have such lexer/parser
dependencies.
Matt Diephouse
> We'll see how I'll do it eventually. Right now I've just begun working
> on a lexer and parser. It would be easy to do if I dropped regular
> expressions support, but the regular expressions syntax makes the
> lexer dependent upon the parser. Though I haven't looked into them
> yet, but I suspect the E4X additions also have such lexer/parser
> dependencies.
I don't know if these will be any help, but I remembered seeing them:
http://perlmonks.org/index.pl?node_id=179555
http://perlmonks.org/index.pl?node_id=192870
They're interesting, if nothing else.
--
matt diephouse
http://matt.diephouse.com
Jeff Clites
> On Sat, 27 Nov 2004 21:49:49 -0500, Michael G Schwern
> <sch...@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.
>
> Yes, it is. :)
You cheated:
Revised^5 Report on the Algorithmic Language Scheme: 50 pages.
But still, small by comparison with most. :)
JEff
Bernhard Schmalhofer
> On Sat, 27 Nov 2004 22:48:42 +0100, liorean <lio...@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.
>
>
>>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.
Hi,
I got started on a ECMAScript-Project, but I haven't really gotten very
far and haven't looked at it since August.
The basis for 'js2pir.js' is narcissus,
http://lxr.mozilla.org/mozilla/source/js/narcissus/, which is a
JavaScript interpreter written in JavaScript.
'narcissus' runs on SpiderMonkey, and the plan was of course to
eventually do the bootstrapping.
I have put the sources on
http://www.schmalhofer.info/schmalhofer/bernhard/projects/oxpecker/.
There are propably a couple of files missing, as I had to recover from
an unfortunate 'make distclean'.
The status is that "Hello World", but not much else, was running in August.
In case that a real ECMAScript-project gets started, I'd be happy to
contribute.
CU, Bernhard
--
**************************************************
Dipl.-Physiker Bernhard Schmalhofer
Senior Developer
Biomax Informatics AG
Lochhamer Str. 11
82152 Martinsried, Germany
Tel: +49 89 895574-839
Fax: +49 89 895574-825
eMail: Bernhard.S...@biomax.com
Website: www.biomax.com
**************************************************
Herbert Snorrason
missed ISO 7185, which is 78 pages and covers Pascal.
> But still, small by comparison with most. :)
That was the point I was trying to make. :)