Re: EcmaScript
Herbert Snorrason wrote: On Sat, 27 Nov 2004 22:48:42 +0100, liorean [EMAIL PROTECTED] 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: [EMAIL PROTECTED] Website: www.biomax.com **
Re: EcmaScript
On Sat, 27 Nov 2004 21:49:49 -0500, Michael G Schwern [EMAIL PROTECTED] wrote: On Sat, Nov 27, 2004 at 09:58:44PM +, 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. :) -- Schwäche zeigen heißt verlieren; härte heißt regieren. - Glas und Tränen, Megaherz
Re: EcmaScript
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. 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
Re: EcmaScript
On Sun, 28 Nov 2004 12:37:03 +0100, James Mastros [EMAIL PROTECTED] wrote: 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. -- David liorean Andersson uri:http://liorean.web-graphics.com/
Re: EcmaScript
On Sun, 28 Nov 2004 23:03:32 +0100, liorean [EMAIL PROTECTED] 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
Re: EcmaScript
At 10:48 PM +0100 11/27/04, liorean wrote: On Sat, 27 Nov 2004 21:11:07 +, Herbert Snorrason [EMAIL PROTECTED] wrote: On Sat, 27 Nov 2004 21:43:01 +0100, liorean [EMAIL PROTECTED] 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 [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: EcmaScript
On Sat, 27 Nov 2004 19:30:20 -0500, Sam Ruby [EMAIL PROTECTED] 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/
Re: EcmaScript
Jeff Clites wrote: On Nov 27, 2004, at 5:58 PM, liorean wrote: On Sat, 27 Nov 2004 19:30:20 -0500, Sam Ruby [EMAIL PROTECTED] 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. - Sam Ruby
