Miranda methods and Methods added by Code Generators

[Andrew Dinn]

On 08/09/2010 05:54 PM, Neal Gafter wrote:
> It comes from the practice of implementing the language.  In other words,
> that was the working definition that we used, even though the definition was
> never published in a publicly available document.  We never did get around
> to producing a compiler specification, which would have been the right place
> to document it.  As a simple example, the compiler-provided default
> constructor is added by the compiler, but it is not synthetic because it is
> supposed to be visible for the purposes of the language.  The synthetic flag
> was systematically added to precisely those symbols that should not be
> visible in the language.

Hmm, now that's interesting because exactly the same kind of rationale 
led us to tag AOP helper methods like getAdvisor() as SYNTHETIC. These 
methods only exist as mechanism to implement semantic extensions (e.g. 
to allow annotations like @Transactional etc to change the way the 
source gets executed). So they should not themselves be susceptible to 
such transformations hence we used SYNTHETIC to make them 'invisible' to 
the transformation process.

Now this may not be the correct attribute for us to be using but maybe 
there ought to be some sort of standard way to identify this category of 
code, not just for AOP but for other transformation processes. I have a 
wider stake in this as my own project, Byteman, also uses code 
transformation and needs to be able to recognise and avoid transforming 
code generated by other transformation processes. I wonder if there is 
any mileage in pursuing this further? Interesting too that the Groovy 
implementation ran foul of the same misunderstanding as we did. Perhaps 
this needs a small subcommittee to discuss it to death :-)

regards,


Andrew Dinn
-----------