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


On 7/10/06, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:

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


> On 10 Jul 2006, at 20:47, Patrick R. Michaud wrote:
>
> >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
>
>




--
Thanks,
Vishal

Reply via email to