On Tue, Jun 14, 2011 at 5:14 PM, Tristan Slominski
<tristan.slomin...@gmail.com> wrote:
> Just for completeness, the lenses you describe here remind me of OMeta's
> foreign rule invocation:
> from http://www.vpri.org/pdf/tr2008003_experimenting.pdf
> see 2.3.4 Foreign Rule Invocation p. 27 of paper, p. 46 of pdf
> So, if you don't like the PEG roots of OMeta, perhaps it's a good reference
> that already works?
The foreign rule invocation let you reuse other grammar but you still
have to carefully declare how the merged grammar should behave. What I
as aiming for was a more dynamic approach in that the "merged" grammar
doesn't exist as such but is just an execution state derived from the
combined program fragments and available lenses. To continue the
Java/SQL example, lets say I had a program like this:
public int totalAmmount(InvoiceNo invoceNo) {
return SELECT SUM(ammount) FROM Invoices WHERE invoiceNo = :InvoiceNo;
}
To make this work I would need three things
1. The java grammar in which the method is declared
2. The SQL grammar in which the expression is declared
3. Something that can translate an SQL expression to a Java
expression, and Java type-errors to SQL type-errors (the lens).
4. A way to annotate the syntax to distinguish Java-syntax from SQL-syntax.
It is step 4 that I think makes it hard to keep a text representation.
A generic syntax to separate any given language would probably be very
convoluted. OTOH extending all languages one want to include to
support grammar switches means that you will end up having to create
those extensions yourself (which could be hard) or live at the mercy
of the syntax-component you depend on. So my fix is to make the
separation a hidden thing, which means the program needs to be
represented in something that allows such hidden things (and I don't
think Unicode control characters is the way to go here).
Btw, if it wasn't clear form the context before, by RAG I meant a
Reference Attributed Grammar.
BR,
John
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
