I've converted one of our antlr3 grammars to anltr4 and it was a breath of
fresh air in how easy it was to get the grammar right. I was quite
impressed.
On Dec 10, 2014 3:06 PM, "Oskar Berggren" <[email protected]> wrote:
> There has been some light discussion in the Hibernate mailing list lately
> regarding antlr4, which seems to have a quite different model compared to
> antlr3. According to the postings, it would require a rethinking of how
> (N)Hibernate handles the syntax trees.
>
> One thing that always bugs me is that almost everything important seems to
> happen inside ("through") constructor calls, or sometime inside method
> calls that are written directly as parameters to a constructor call. I find
> myself repeatedly stepping over such code during debugging, only to realise
> I now have to start over because hidden behind that fairly innocent-looking
> new X(y, z, x.GetTranslatorOrWhatever()) was actually the brunt of the
> logic.
>
> The way that several antlr parsers are involved also surprised me
> originally.
>
> /Oskar
>
> 2014-12-10 22:50 GMT+01:00 Gunnar Liljas <[email protected]>:
>
>> I'm currently investigating a bit of query functionality in NHibernate
>> and I'm losing all of my hair, since I've ended up in the HqlSqlWalker
>> (there generated code part).
>>
>> I understand why the "new" Linq provider was built on top of the Hql
>> parts, but at the same time it's a part of Nhibernate's code base that I
>> really, really ha......don't like.
>>
>> A Linq expression tree is transformed into a ReLinq query model.
>> The query model is transformed into an intermediate Hql tree
>> The intermediate tree is transformed into "the real" Hql tree
>> The Hql tree is eventually transformed into SQL
>>
>> The performance hit of all this may be neglible, but the complexity hit
>> is insane. There is at least one tree to many and the complexity of the
>> HqlSqlWalker is making it impossible to work with. It's not meant to be
>> worked with, but having core functionality in a black hole is annoying.
>> Going from a ReLinq query model to SQL will always be complex stuff, but it
>> shouldn't have to be this convoluted.
>>
>> At some point I think it would make more sense to reverse the model, so
>> that the Hql is processed into a syntax tree optimized for productive and
>> performant Linq.
>>
>> Thoughts?
>>
>> /G
>>
>> PS. At certain points the HqlSqlWalker calls HandleClauseStart, which
>> sets _currentClauseType, There is no corresponding HandleClauseEnd to pop
>> the state, which means that _currentClauseType can actually be wrong. In
>> my test code that meant that the parser though it was inside a subquery
>> when it actually wasn't any longer. Just an example of the kind of
>> weirdness that is almost impossible to debug, and even harder to do
>> something about once you find the problem. DS
>>
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "nhibernate-development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "nhibernate-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
---
You received this message because you are subscribed to the Google Groups
"nhibernate-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
