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

[Kevin Reid]

On Oct 24, 2007, at 18:31, ihab.awad at gmail.com wrote:
> 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?

No. Try looking at the expansion (interp.setExpand(true)) --  
quasiliterals are entirely a runtime feature.

   ? interp.setExpand(true)
   ? term`foo`
   # expansion: term__quasiParser.valueMaker("foo").substitute 
(__makeList.run())

   # value: term`foo`

> 2. It seems that the org.quasiliteral.quasiterm package is in some
> ways more "general" than the org.quasiliteral.term package. Is that
> correct?

org.quasiliteral.term provides ordinary terms.

org.quasiliteral.quasiterm provides term *templates* -- they can  
contain quasi-holes.

> 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;

No.

1. You should not need to alter any Java code distributed with E.

2. ScopeSetup defines the standard E environment; applications should  
use <import> to make use of added objects.

3. QBuilder is specifically for quasiterms, the quasi-template-form  
of term-trees.

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

No. org.quasiliteral is not your namespace to play with unless MarkM  
says so, and profligate code duplication is not a good idea.

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

I believe this is a bad idea.

However, here's something you could do:

1. Define a mapping between JavaScript syntax and term-trees.
2. Write a quasi-parser which turns JavaScript syntax into quasiterm  
trees.

You would then get the data model and quasi-hole semantics of term  
trees, but with JavaScript surface syntax. Whether this is suitable  
depends on how you want to treat JavaScript.

> 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?

Yes.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>