[e-lang] Starting point for a new quasi-parser?

[ihab.awad at gmail.com]

Thanks for the help --

On 10/22/07, Kevin Reid <kpreid at mac.com> wrote:
> http://erights.org/javadoc/org/quasiliteral/base/QuasiExprParser.html
> http://erights.org/javadoc/org/quasiliteral/base/QuasiPatternParser.html
> http://erights.org/javadoc/org/quasiliteral/base/MatchMaker.html
> http://erights.org/javadoc/org/quasiliteral/base/ValueMaker.html

I tried looking through the code; I am hoping to get a quick prototype
by re-using at least some of the Astro implementations as much as
possible. To that end, I've been looking at the how the
term__quasiParser sublanguage works. Here are some questions --

1. I notice that org.quasiliteral.term.TermBuilder is invoked each
time E language code is interpreted. I imagined that this is only
invoked when "term`foo`" expressions are parsed. So I guess the E
parser itself is inextricably tied to this material?

2. It seems that the org.quasiliteral.quasiterm package is in some
ways more "general" than the org.quasiliteral.term package. Is that
correct? If yes, then I was confused about why class
org.quasiliteral.quasiterm.QBuilder contains references to
org.quasiliteral.term.TermBuilder (the more "specific" code). I see
that this is then punched into the global scope in
org.erights.e.elang.interp.ScopeSetup. So given that I want to build a
JavaScript quasi-parser, should I be doing --

a. Add another static to QBuilder, say "javascript__quasiParser", and
wiring it up inside ScopeSetup;

b. Creating a package org.quasiliteral.javascript, duplicating the
stuff in org.quasiliteral.term; and

c. Editing my new package org.quasiliteral.javascript to change the syntax?

3. It seems like the Antlr support is a work in progress at the
moment, and the main stuff is based on Yacc. Is that correct?

Ihab


Ihab

-- 
Ihab A.B. Awad, Palo Alto, CA