Java Script in Parrot

[Vishal Soni]

Hi,

Is any one working on Java Script(ECMA-262) implementation in Parrot?

--
Thanks,
Vishal

[Norman Nunley]

I've started work on a Javascript implementation, but haven't gotten
very far yet.
I've starting with the Narcissus implementation from the Mozilla
project. My current
plan is to:
1. Identify any objects that need to be bootstrapped into PMCs.
2. Write a Compile phase that borrows logic from jsexec.js, and
convert it to
a PIR generator.
3. Run it once in a Narcissus enabled SpiderMonkey interpreter.

The Mozilla project has a huge suite of tests for EMCAScript
compliance, which might be
a good thing to borrow for any Parrot based Javascript implementation.

Regards,

Norman Nunley

[Vishal Soni]

Hi Norman,

I am also in the implementing Java Script for Parrot. But the approach I
have taken is, that I picked up the ECMA-262 Spec 3rd Edition and I have
implemented in Parrot Grammar Engine (PGE).

Write now I have implemented more than half of Java Script grammar in
PGE to compile correctly.

My game plan is as follows:

1. Implement Java Script Grammar in PGE
2. Convert PGE-> PAST.
3. Convert PAST-> POST.
4. Convert POST-> Byte code.

I have seen the Test bed from Mozillla and I plan to start using it once
I have a testable implementation.

I am not an expert on which approach is the way to go:
1. Hack Mozilla's JavaScript excution engine to generate PIR.
2. Use the Compiler Tool Chain developed by Parrot Wizards to implement
JavaScript engine.

Parrot experts any thoughts or comments.

Any feedback as to how to unify the efforts if possible would be highly
valuable.

-Vishal Soni

[Mehmet Yavuz Selim Soyturk]

I am too planning to implement ECMAScript. I do not yet know how, I
have to experiment with parrot first.

[Chromatic]

On Sunday 09 July 2006 02:15, Vishal Soni wrote:

> I am not an expert on which approach is the way to go:
> 1. Hack Mozilla's JavaScript excution engine to generate PIR.

If there's a fairly direct correspondence between JS bytecode (if there is
such a thing; I have no idea -- whatever internal ops it uses to represent a
program to execute), this may be easiest to start.

> 2. Use the Compiler Tool Chain developed by Parrot Wizards to implement
> JavaScript engine.

This is probably the best long-term approach, at least if you find someone
good to write the grammar. (I hate parsing.)

Both approaches will probably need the same custom PMCs and built-ins, so
whichever approach gets you to that point first is the most reasonable
choice, in my opinion.

-- c

[Patrick R. Michaud]

On Sun, Jul 09, 2006 at 04:11:55PM -0700, chromatic wrote:
> On Sunday 09 July 2006 02:15, Vishal Soni wrote:
>
> > I am not an expert on which approach is the way to go:
> > 1. Hack Mozilla's JavaScript excution engine to generate PIR.
>
> If there's a fairly direct correspondence between JS bytecode (if there is
> such a thing; I have no idea -- whatever internal ops it uses to represent a
> program to execute), this may be easiest to start.
>
> > 2. Use the Compiler Tool Chain developed by Parrot Wizards to implement
> > JavaScript engine.
>
> This is probably the best long-term approach, at least if you find someone
> good to write the grammar. (I hate parsing.)

FWIW, I'm more than happy to help with the grammar, especially if
there's an existing definition to work from.

Pm

[Patrick R. Michaud]

On Mon, Jul 10, 2006 at 09:19:14PM +0100, Norman Nunley, Jr wrote:
> There's a rules grammar in http://svn.openfoundry.org/pugs/misc/
> JavaScript-FrontEnd/Grammar.pm
>
> When I last attempted to compile it with PGE, it gave up the ghost in
> the character class definitions.

Wow, thanks for the update. PGE seems to be having trouble with
the <-xyz> rules, which are currently unimplemented. But the
grammar is also using incorrect regex syntax -- the statements
like:

rule no_LineTerminator_here {
[ <ws> & <-<LineTerminator>>*? ]
}

rule USP { <<Zs>-<TAB>-<VT>-<FF>-<SP>-<NBSP>> }

need to eliminate the inner angles, as in:

rule no_LineTerminator_here {
[ <ws> & <-LineTerminator>*? ]
}

rule USP { <+Zs-TAB-VT-FF-SP-NBSP> }

But I think the no_LineTerminator_here rule probably needs
to be rewritten altogether to avoid the & conjunction.

At any rate, this is a very useful start; I think it could
be updated quite quickly. Thanks!

Pm

[Vishal Soni]

Hi Patrick,

This is is a good starting point. I have been writing the JavaScript grammar
in PGE fromECMA-262 spec. They lay out the operator precedence using Grammar
rules. Instead of using rules for operator precedence I would like to use
your optok approach. Is there some help I can get? I did look at your YAPC
2006 presentation. Are there any code examples?

The other that would be great to have is if we could suport Unicode
Character classes in PGE for e.g. <[\u2028-\u2050]>. JavaScript
specification assumes that the Source could be in Unicode format.

-Vishal

--
Thanks,
Vishal

[Chris Dolan]

On Jul 10, 2006, at 4:31 PM, Vishal Soni wrote:

> This is is a good starting point. I have been writing the
> JavaScript grammar
> in PGE fromECMA-262 spec. They lay out the operator precedence
> using Grammar
> rules. Instead of using rules for operator precedence I would like
> to use
> your optok approach. Is there some help I can get? I did look at
> your YAPC
> 2006 presentation. Are there any code examples?

Take a look at parrot/languages/punie/lib/{punie.pg,PunieGrammar.pir}
which has both bottom up and top down parsing. I found it very
educational.

Chris

--
Chris Dolan, Software Developer, http://www.chrisdolan.net/
Public key: http://www.chrisdolan.net/public.key
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

[Vishal Soni]

Thanks Chris

I looked at it but it does not implement Unicode in PGE and Optok too..

[Will Coleda]

Punie has an example of optok parsing.

APL has an example of utf-8 grammar.

Regards.

--
Will "Coke" Coleda
wi...@coleda.com