Sorting the list should be inconsequential, but you seem to miss my concern, which is about the loop nesting:
A) for each transform in list, visit each node B) for each node, visit by each transform in list In case B, transforms wouldn't entirely execute as distinct "layers" across the compilation unit but would rather be interleaved as the compiler proceeds through the AST. In that case, the effect of ordering is highly constrained. On Wed, Jan 20, 2021, 18:54 MG <mg...@arscreat.com> wrote: > 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... ? > > Cheers, > mg > > > 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 <mg...@arscreat.com> 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 >> > (https://github.com/spockframework/spock/issues/83); 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? >> >> >
