[hibernate-dev] Query handling : Antlr 3 versus Antlr 4

[Steve Ebersole]

On Tue, Jun 9, 2015 at 10:14 AM Gunnar Morling <gunnar at hibernate.org> wrote:

Yes, indeed I cheated here a bit. Probably it should be the following
> instead:
>
>       [DOT] ---> AttributeReference("<gen:1>", "code")
>         [DOT]
>           [DOT]
>             [IDENT, "c"]
>             [IDENT, "headquarters"]
>           [IDENT, "state"]
>         [IDENT, "code"]
>

How do you identify one DOT as referring to something else versus any of
the other DOTs?


Or maybe something like:
>
>     [SELECTION_PARTICLE] ---> AttributeReference("<gen:1>", "code")
>       [DOT]
>         [DOT]
>           [DOT]
>             [IDENT, "c"]
>             [IDENT, "headquarters"]
>           [IDENT, "state"]
>         [IDENT, "code"]
>
> Where SELECTION_PARTICLE would be an abstract representation of anything
> that can be selected (attribute ref, Java literal ref etc.) and the
> decorator element added in a later pass would specify its actual semantics
> based on the alias definitions etc. discovered before.
>
> Bottom line being, that decorators providing semantics are attached to the
> nodes of the parse tree based on information gathered in previous passes.
>

And what does that look like in real, practical terms?   That's what
concerns me :)  I don't know, and you are just speaking in generalities.
So what does that look like in practice?


Not into the tree itself, but we can encode that semantic resolution into
> decorators (node attachments).
>

Again, what do these "node attachments" look like in  practice?  I have
zero clue and based on my discussions with Antlr folks its not pretty.
Maybe I misunderstand.  But if you are proposing this approach, I would
think you should have an idea of how it would look practically-speaking :)
 Maybe this is the way to go, I just need to see what this looks like.


Yes, they would deal with [[DOT][IDENT]] nodes but would benefit from
> semantic decorators attached previously. During rendering I would expect
> mainly those attachments to be of importance for the query creation.
>
> Admittedly, that's all quite "high level", but so far it seems doable to
> me in principle. It doesn't answer of course actual tree transformations
> such as (x + 0) -> x. I am not sure whether there are cases like this.
>

Yes it is all extremely high-level.  That is my concern.  Principle and
practice are often 2 very different things.

I plan on spending some time taking my hibernate-antlr4-poc project and
expanding it specifically to try the "second grammar" approach and see what
practical difficulties that shakes out.  Would you be willing to do the
same for this decorated approach?  Then we'd have concrete stuff to compare
and base a decision on.

Also, `(x + 0) -> x` is actually a quite simple case.   Ours is much more
complicated.  In analyzing `c.headquarters.state.code` in the SELECT clause
we need a few things to happen in a few different parts of the tree.  We
need:
1) `c.headquarters.state` to be transformed into 2 "implicit joins" in the
FROM clause
2) we need to replace `c.headquarters.state.code` as
`{implicit-alias}.code` in the SELECT
3) register `c.headquarters` and `c.headquarters.state` as implicit join
paths (additional implicit joins using these paths should re-use the same
joins).