SDA SE Wiki

Software Engineering for Smart Data Analytics & Smart Data Analytics for Software Engineering

User Tools

Site Tools


Differences

This shows you the differences between two versions of the page.

Link to this comparison view

research:jtransformer:scratchpad [2018/05/09 01:59] (current)
Line 1: Line 1:
 +**... Warning: this page is currently being edited ...**
  
 +----
 +
 +====  Normalized representation for annotations ====
 +
 +
 +I suggest to add only the following two extensions to the PEF language:
 +
 +
 +  * ''​annotationT(#​id,​ #parent, #encl, #​annotationType )'' ​
 +  * ''​annotationParamT(#​id,​ #parent, Position, Name, Value )''​ were Value can be either an atom or an ID.
 +
 +**#​id:​**\\ ​
 +The unique ID assigned to this fact.
 +
 +
 +
 +**#​parent:​**\\ ​
 +The parent element.
 +In ''​annotationT''​ the ID of the annotated element. In ''​annotationParamT''​ the id of the annotation to which this parameter belongs.
 +
 +
 +
 +**#​encl:​**\\ ​
 +The **(nearest or outmost ???)** enclosing annotated declaration,​ expression or statement.
 +Annotation of expressions and statements extended the Java 5 annotation model. //NOTE: This extension departs from the semantics that '​enclosing'​ has for all other code elements. --GK //
 +
 +
 +
 +**annotationType:​**\\ [[classdeft|classdeft]]\\ ​
 +The referenced annotation type.
 +
 +
 +
 +**Value:​**\\ ​
 +atom,​[[literalt|literalt]],​[[newarrayt|newarrayt]],​[[identt|identt]],​ [[conditionalt|conditionalt]]. \\ //Values that can be either atoms or identities are not supported so far. So we will need an 
 +artificial extra element just for giving atoms an identity. Not nice. There is something wrong 
 +in our basic representation - we should rethink the assumptions behind ast_node_def/​3. -- GK //
 +
 +
 +=== AST Specification ===
 +<​Code>​ ast_node_def('​Java',​annotationT,​[
 +     ​ast_arg(id, ​    ​mult(1,​1,​no ), id,       ​[id]),​
 +     ​ast_arg(parent,​ mult(1,1,no ), id,       ​[id]),​ % <-- convention!!!
 +     ​ast_arg(encl, ​  ​mult(1,​1,​no ), id,       ​[id]),​
 +     ​ast_arg(annotationType,​ mult(1,1,no ),​id,​[classDefT]),​
 +]).
 +
 +ast_node_def('​Java',​annotationParamT,​[
 +     ​ast_arg(id, ​    ​mult(1,​1,​no ), id,       ​[id]),​
 +     ​ast_arg(parent,​ mult(1,1,no ), id,       ​[annotationT]),​ % <-- convention!!!
 +     ​ast_arg(position,​ mult(1,1,no ),​attr, ​   [atom]),
 +     ​ast_arg(name, ​  ​mult(1,​1,​no ), attr,     ​[atom]),​ %  <-- redundant, could be removed
 +     ​ast_arg(value, ​ mult(1,1,no ), id,       ​[annotationExpressionType])
 +]).</​Code>​
 +====  Discussion ​ ====
 +
 +This representation respects the functional dependencies of the represented entities. ​
 +
 +Thus it is redundancy-free. ​
 +
 +
 +
 +It simplifies the creation and use of annotations since it does not need to distinguish special cases, following ​
 +one simple general principle: Every annotation is represented by
 +
 +
 +  * an ''​annotationT(annot,​ p, enc, type)''​ fact
 +  * and one ''​annotationParamT(paramId,​ annot, Position, Name, Value )''​ fact for every parameter
 +
 +Examples for the implied representation of the special cases mentioned in Tobias'​ proposal are given below.
 +
 +
 +===  Fully Parameterized Annotation (General Case) ===
 +
 +
 +Source Example:  ​
 +
 +<​Code>​ @ThisAnnotation(id = 1, clazz = MyClass.class) </​Code> ​
 +
 +Fact representation:​
 +
 +<​Code>​
 +annotationT(annot,​ p, enc, type).
 +annotationParamT(ap1,​ annot, enc, 1, id, 1). 
 +annotationParamT(ap2,​ annot, 2, clazz, '​MyClass.class'​).</​Code>​
 +
 +Query for the value of the second parameter:
 +
 +<​Code>​
 +   ...,
 +   ​annotationT(Annot,​ P, Enc, Type),
 +   ​annotationParamT(Param,​ Annot, 2, _, Value). </​Code>​
 +
 +Query for the value of the parameter named clazz:
 +
 +<​Code>​
 +   ...,
 +   ​annotationT(Annot,​ P, Enc, Type),
 +   ​annotationParamT(Param,​ Annot, _, clazz, Value). </​Code>​
 +===  Single member annotation ​ ===
 +
 +
 +Source Example:  ​
 +
 +<​Code>​ @ThisAnnotation("​Value"​) </​Code> ​
 +
 +Fact representation:​
 +
 +<​Code>​
 +annotationT(annot,​ p, enc, type).
 +annotationParamT(ap1,​ annot, 1, null, '​Value'​). </​Code>​
 +The name of the argument could be ignored or explicitly set to '​null'​.
 +Alternatively,​ names could be eliminated completely, translating them to argument positions.
 +
 +Query for the value of the only parameter:
 +
 +<​Code>​
 +   ...,
 +   ​annotationT(Annot,​ P, Enc, Type),
 +   ​annotationParamT(Param,​ Annot, 1, _, Value). </​Code>​
 +===  Single member annotation ​ ===
 +
 +
 +Source Example:  ​
 +
 +<​Code>​ @ThisAnnotation </​Code> ​
 +
 +Fact representation:​
 +
 +<​Code>​
 +annotationT(annot,​ p, enc, type).</​Code>​
 +
 +Query for the marker annotation:
 +
 +<​Code>​
 +   ​..., ​
 +   ​annotationT(Annot,​ P, Enc, Type).</​Code>​
 +====  Rationale ====
 +
 +
 +annotationParamT has no enclosing'​ argument since that would be fully redundant with the enclosing of its parent.
 +The typical accesses shown above always go through the parent. ​
 +
 +
 +
 +In the long term, derivable information such as '​enclsing'​ should not be hardcoded anymore but specified by 
 +explicit rules whose extension can be materialized if necessary for optimization:​
 +
 +<​Code>​contained_in_method(Method,​ Element)</​Code>​
 +====  Open Issues ====
 +
 +  * Names versus Parameter positions (I favour throwing names away --GK).
 +  * Hybrid values (atoms or IDs) are not supported, so we need an additional level of indirection compared to my example for single-value annotations.
 +==== TR: Comments on your solution ====
 +
 +There are some good ideas, but I would like to take back some of them.
 +A general comment: In your enumeration of normalized elements you forgot to list markerAnnotationT and annotationMemberT.
 +
 +
 +
 +
 +
 +First, what I would like to take over:
 +
 +
 +  * Removing expression from annotationT and adding a memberValueT aka annotationParamT is fine for me.
 +  * Same goes for the encl reference in memberValueT.
 +  * Inlining the primitive types and strings sounds like a good idea, too. This will avoid indirections in several cases. Although the specification gets quite dirty. ​
 +  *
 +    * Your ''​specification ast_arg(value, ​ mult(1,1,no ), id,       ​[annotationExpressionType])''​ is not correct. Since the argument could be an "​attr"​(ibute) or an "​id"​. This is (currently) not expressible in ast_node_def. I think this would cause a lot of problems. But still - I like the idea.
 +  *
 +    * I see one problem here - ids could be memberValueT(...,​ 111) could be an id or an attribute.
 +  *
 +    * **I just saw you comment on hybrid values. This job is already carried out by literalT facts! ​ So we do not have to change anything here.**
 +
 +What I did not understand / do not agree on (yet):
 +
 +
 +  * type epxression should not be inlined (classname.class) You throw away the binding to the type without a reason
 +  * We should use Java Lang Spec terms: I don't want to introduce annotationParamT. They use consistently "​member value"​.
 +  * Why do you want to throw away the attribution of the memberValueT PEF? 
 +  * I don't get the reason for the position argument. I assume you are referinng to the parameter position. Why should we put this into the parameter itself and externalize it? By now it is embedded in the parent in every other PEF (classDefT, ...).  I know that you don't like this, but this should be changed consistantly and not just in one place. Maybe I got the position argument wrong: Why should name be redundant here? Are you refering to the annotation member position? If not - the order of parameters is arbitrary, that's what the names are for. 
 +
 +
 +
 +
 +
 +Updated
 +
 +<​Code>​
 + ​ast_node_def('​Java',​annotationT,​[
 +     ​ast_arg(id, ​    ​mult(1,​1,​no ), id,       ​[id]),​
 +     ​ast_arg(parent,​ mult(1,1,no ), id,       ​[id]),​
 +     ​ast_arg(encl, ​  ​mult(1,​1,​no ), id,       ​[id]),​
 +     ​ast_arg(annotationType,​ mult(1,1,no ),​id,​[classDefT]),​
 +     ​ast_arg(values,​ mult(0,​*,​ord ),id,       ​[memberValueT]) % <- a general redundancy problem of our current AST
 +]).
 +
 +
 +ast_node_def('​Java',​memberValueT,​[
 +     ​ast_arg(id, ​    ​mult(1,​1,​no ), id,   ​[id]),​
 +     ​ast_arg(parent,​ mult(1,1,no ), id,   ​[id]), ​
 +%     ​ast_arg(name, ​  ​mult(1,​1,​no ), attr, [atom]), % <- redundant information,​ contained in ref
 +     ​ast_arg(value, ​ mult(1,1,no ), id,   [ annotationExpressionType]), ​
 +     ​ast_arg(ref, ​   mult(1,1,no ), id,   ​[annotationMemberT])
 +]).</​Code>​
research/jtransformer/scratchpad.txt · Last modified: 2018/05/09 01:59 (external edit)

SEWiki, © 2019