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
<mailto: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
<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?
