groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <>
Subject Re: Ordering of AST transformations
Date Thu, 21 Jan 2021 00:54:33 GMT
Hi Chris,

from what Eric said, it seems it is just some (linked) lists that are 
being processed after the data has been collected, that sounds like 
these would need to be replaced with a priority ordered collection or 
sorted after they have been filled.
That does not sound too complicated in principle, but I am wondering if 
a potential increase in compile time is something we would need to be 
worried about here... ?


On 20/01/2021 23:25, Christopher Smith wrote:
> I'm open to tinkering on it, but my understanding of the compiler 
> Internals is extremely limited. If more knowledgeable people say that 
> the existing order is arbitrary, then I can dig into it.
> The top potential blocker that I was unsure about is that ASTTs might 
> not be processed "atomically"; that is, given two nodes N1 and N2 each 
> tagged for T1 and T2, is the execution order (T1(N1), T1(N2), T2(N1), 
> T2(N2)) or (T1(N1), T2(N1), T1(N2), T2(N2))? If the latter (that all 
> ASTTs are processed on a given node in encounter order before 
> proceeding to the next), then my suggestion is likely infeasible with 
> the current architecture, or at least it would not provide the 
> benefits desired.
> On Wed, Jan 20, 2021, 16:08 MG < 
> <>> wrote:
>     Hi Chris,
>     to make things clear: Would you offer to work on this feature, or
>     is it
>     "just" a feature request on yopur part ?-)
>     In any case, your proposal sounds like a good idea. It is always
>     amazing
>     to me, how many things are unecessarily hard or even impossible to do
>     because - by design - "the order of execution" of operations
>     "cannot be
>     guaranteed". While potential execution in parallel is often given
>     as a
>     reason for this, the design often predates these notions, so in
>     reality
>     there often is no good explanation except the all time classic: It
>     was
>     easiest to implement to do things in some sort of internal or natural
>     order ;-)
>     I had a quick look at Spring @Ordered, and they use int values for
>     the
>     ordering. From the top of my head it feels it might be a good idea
>     if we
>     used String or BigDecimal instead, since that should guarantee
>     that one
>     can always fit another value between existing ones (by adding another
>     letter / digit) :-)
>     Cheers,
>     mg
>     On 20/01/2021 08:01, Christopher Smith wrote:
>     > A longstanding shortcoming of the AST-transformation system is the
>     > minimal guarantees provided when multiple ASTTs target the same area
>     > of code. While comprehensive support for this seems like it would
>     > require a redesign or at least major rework, I have a suggestion
>     for a
>     > small change that might get a large segment of use cases working.
>     >
>     > I propose adding "order" directives to transforms akin to Spring's
>     > @Ordered and @AutoConfigureBefore/After. The sole effect of these
>     > directives would be to instruct the compiler to run identified
>     > transformations in sorted sequence.
>     >
>     > As a specific hands-on use case, there's been a feature request open
>     > against Spock for 5 years to support stateful traits
>     > (
>     <>); the
>     impediment is
>     > that both Spock and traits are implemented as SEMANTIC_ANALYSIS
>     ASTTs,
>     > so that Spock doesn't see the trait fields with their @Shared
>     > annotations when it runs.
>     >
>     > Is something like this feasible, or does it conflict with existing
>     > sequencing or traversal requirements inside the compiler processing?

View raw message