[antlr-interest] De-emphasizing tree grammars?

Kyle Ferrio kferrio at gmail.com
Fri Dec 23 19:38:47 PST 2011


Delurking...

I will probably sound like a crank, but everything good starts with an itch.

I've said this before, but you said it best:  "I very much dislike hybrid
languages."

I recognize that this message may not find much quarter in a world in which
inlining php or javascript in html is actually considered reasonable.
Inlining impairs readability and may increase the  complexity (cost) of
testing.  And an even greater cost of inlining is the loss of portability
of grammars to new targets.  Wouldn't it be nice to write and test a
grammar, say, for an SQL dialect exactly once and know that it can be
retargeted for multiple runtimes in constant time?  Yes, but avoiding
inlining turns out to be a lot harder than it sounds.  But it is
seductive...

A well defined Neutral Implementation Pattern Language, viz. a
pseudo-target could be a useful compromise with the following benefits: (1)
enabling target-agnostic validation; (2) accelerating simultaneous,
synchronous development of both antlr and targets (a major problem
currently imho) by providing a thin shim targeted by antlr and known in
advance by authors of target generators; and (3) promoting reusuability and
readability of grammars via abstraction of the implementation.

Note that adding a neutral pseudotarget is completely compatible with
existing inlined "native" targets.  Any of us could in principle create a
pseudotarget now, given time and insight...I'm seriously short of both
right now but am looking forward to maybe thinking about this once antlr v4
lands.
 On Dec 23, 2011 6:40 PM, "Jason Osgood" <jason at jasonosgood.com> wrote:

> Hi Gavin.
>
>
> Read your Hibernate book. Respect.
>
> re: Syntax trees.
>
> What's a "typed syntax tree" is. From looking at your code, it's a
> Java class hierarchy representing the parts of your language and you
> build an object graph representing a program. Verse a parse tree, AST,
> or DOM. Using your objects for "nodes" instead of untyped DOM or parse
> nodes.
>
> Right?
>
> Just skimmed your Ceylon.g. I totally forgot about that strategy
> (using ANTLR rules with parameters and return values).
>
> I've done that. I didn't like it. Instead of stitching an object graph
> together with inlined Java, I opted instead to use a Builder. Method
> calls and an internal stack instead of "new" and assignment. Wasn't
> much better.
>
> I very much dislike hybrid languages. Stuff like inlining Java in
> one's grammar, C#'s LINQ, template languages. I have a hard enough
> time understanding one language at a time.
>
> Any way.
>
> Next time, for my ARON project, I'll subclass DebugEventListener and
> move all that bookkeeping there. Builders are still complicated, true.
> That's just the nature of Builders. But at least the Builder and
> grammar are distinct.
>
> One benefit I anticipate is reduced cost of change and testability. I
> plan to use gunit (or something). Which (I think) would be more
> difficult with inlined Java code gumming up the works.
>
> I DON'T build a "typed syntax tree" in my fado project for a couple
> reasons. My pathetic efforts to build a generic SQL object model were
> easily defeated. What I really needed to do was find and replace the
> interesting bits. By leaving the parse tree in place, I was able to
> reemit the input stream with just the interesting bits changes,
> preserving formatting, comments, etc.
>
> The Ceylon and fado use cases are very different. But I think moving
> inlined Java code out of our grammars is a positive step forward.
>
> Which is why I posted my original question. Debug event listener hooks
> are only generated with a command switch. Terence didn't anticipate
> they'd be used like this.
>
> Thinking about it, I should probably mention:
>
> ANTLR's DebugEventListener is kinda like a SAX EventListener. But much
> better. Partially because all things XML, especially SAX (and
> namespaces, and angle brackets, and...), are a terrible bight on the
> Earth and should be eradicated with prejudice. But mostly because it's
> direct and concise. If some lost soul wants a SAX event source, let
> them write an adapter.
>
>
> Cheers, Jason
>
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe:
> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
>


More information about the antlr-interest mailing list