On Wed, Jun 17, 2015 at 7:39 AM Gunnar Morling
> Yes, having such extension point seems reasonable. OGM would probably use
> the same implementation as ORM, but other users may plug in another impl
> based on their own type of entity definitions. Would the scope of that
> extension point be solely
I have committed a lot of work on this PoC to my upstream repo.
The initial walk to process the explicit from-clause is pretty much done.
Overall I really like the shape of FromClause, FromElementSpace and
FromElement. One question of structure here I have not decided yet is the
relationship of j
This seems very similar to what I had in mind with the decorator stuff. The
decorating elements would represent that manually implemented semantic tree.
In the end it probably doesn't even matter whether the elements of that
tree would have links to the parse tree elements they originated from or
Hi,
> resolving possible unqualified attribute references [...]
> The other option is to have such an API. This would allow the parser to
ask the consumer whether the given identifier (`ssn`) is a persistent
attribute of any of the available entities.
Yes, having such extension point seems reaso
I am not so sure that manually building a tree that would work with
listeners/visitors generated from a second grammar is going to be an
option. I have asked on SO and on the Antlr discussion group and basically
got no responses as to how that might be possible. See
https://groups.google.com/foru
I just pushed my initial work on performing some indexing of explicit from
clauses. Essentially it takes the from clauses defined in the query and
begins the massage process. From here I will start working on handling
implicit from-clause-elements. Part of that however will require me being
able
In the re-write case we will have to decide between 2 courses.
The problem lies in the fact that the listeners and visitors expect a tree
specifically generated from the grammar that generated them. For HQL, say
we have one grammar named HqlParser (like in the poc). The listeners and
visitors bu
2015-06-09 22:11 GMT+02:00 Steve Ebersole :
> So today I spent some time cleaning up the basic HQL parser. Personally I
> think it would be best if our 2 proof-of-concepts could share that first
> grammar. IMO that would make the differences between the 2 approaches more
> apparent. I will push
So today I spent some time cleaning up the basic HQL parser. Personally I
think it would be best if our 2 proof-of-concepts could share that first
grammar. IMO that would make the differences between the 2 approaches more
apparent. I will push those changes soon.
It is not complete yet. But it
On Tue, Jun 9, 2015 at 10:14 AM Gunnar Morling wrote:
Yes, indeed I cheated here a bit. Probably it should be the following
> instead:
>
> [DOT] ---> AttributeReference("", "code")
> [DOT]
> [DOT]
> [IDENT, "c"]
> [IDENT, "headquarters"]
>
2015-06-09 16:02 GMT+02:00 Steve Ebersole :
> On Tue, Jun 9, 2015 at 3:57 AM Gunnar Morling
> wrote:
>
> What I like about the Antlr4 approach is the fact that you don't need a
>> set of several quite similar grammars as you'd do with the tree
>> transformation approach. Also using the current ve
On Tue, Jun 9, 2015 at 5:50 AM Sanne Grinovero wrote:
Do you mean that you would be ok to "navigate" all the [DOT] nodes to
> get to the decorated attachments?
> In that case while you might be fine to translate each fragment into a
> different fragment, it's not straight forward to transform it
On Tue, Jun 9, 2015 at 3:57 AM Gunnar Morling wrote:
What I like about the Antlr4 approach is the fact that you don't need a set
> of several quite similar grammars as you'd do with the tree transformation
> approach. Also using the current version of Antlr instead of 3 appears
> attractive to me
2015-06-09 12:49 GMT+02:00 Sanne Grinovero :
> On 9 June 2015 at 09:56, Gunnar Morling wrote:
> > Hi Steve,
> >
> > Did you ever have a chance to apply the "decorated parse tree" approach
> to
> > your Antlr4 PoC?
> >
> > What I like about the Antlr4 approach is the fact that you don't need a
> s
On 9 June 2015 at 09:56, Gunnar Morling wrote:
> Hi Steve,
>
> Did you ever have a chance to apply the "decorated parse tree" approach to
> your Antlr4 PoC?
>
> What I like about the Antlr4 approach is the fact that you don't need a set
> of several quite similar grammars as you'd do with the tree
Hi Steve,
Did you ever have a chance to apply the "decorated parse tree" approach to
your Antlr4 PoC?
What I like about the Antlr4 approach is the fact that you don't need a set
of several quite similar grammars as you'd do with the tree transformation
approach. Also using the current version of
As most of you know already, we are planning to redesign the current
Antlr-based HQL/JPQL parser in ORM for a variety of reasons.
The current approach in the translator (Antlr 2 based, although Antlr 3
supports the same model) is that we actually define multiple
grammars/parsers which progressivel
17 matches
Mail list logo
