(check another language specification - e.g., Java - and see the kind of structure that is used)

(new language for Weaver Specification; explain syntax; 'functions' instead of 'attributes')

(change 'attribute' to 'function')

Previous syntax:

   $jp.exec result : <action_name>;

New syntax:

   var result = $jp.exec <action_name>;

If 'result' is a variable that already exists, 'var' can be omitted:

   result = $jp.exec <action_name>;

The keyword '.exec' can be omitted if you prefix the name of the action with the target join point, and add parenthesis:

  result = $jp.<action_name>();

/* (recommended syntax: $jp.exec <action_name>. Could it be $jp.action <action_name> instead?) */

There are several actions that are defined by default in the LARA language.

• only supports before/after, around/replace removed
• granularity is statement level
• Consider supporting joinpoints as input, instead of only literal text

(granularity is node itself)

Previous syntax:

   call result : AnAspect();

New syntax:

   var result = call AnAspect();

(independent of weaver)

Should return: → executionTime → stdOut → stdErr → exitStatus

(Should return the same as 'cmd', additionally can define a report)

Parts of the language that have not been decided yet and are still under discussion

Currently LARA has no way to define when we do a 'select', if we want just the direct joinpoints under it (e.g., children) or all its descendants.

E.g., select body.loop end will recursively return all the loops inside the body, there is no simple way to select only the loops that are directly under the body (excluding nested loops).

Add joinpoints specifically for direct children selection. 'select function.stmt' selects all statements, 'select function.childStmt' selects only the direct children of the function.

/*

It is not defined the order of consecutive calls to insert before/after. If we do:

select a end
  $a.insert before 'before_1';
  $a.insert after 'after_1';
  $a.insert before 'before_2';
  $a.insert after 'after_2';
end

Should it appear like this:

'before_2'
'before_1'
a
'after_1'
'after_2'

Or like this?

'before_1'
'before_2'
a
'after_2'
'after_1'

Always insert the closest possible to the node. For the previous example, this means that the insertion order would be like:

'before_1'
'before_2'
a
'after_2'
'after_1'

*/

/*

Currently, the preferred way to do String literals in LARA is to use quotes:

'a string in LARA'

LARA also supports double quotes, but they are internally translated to single quotes, so there can be problems when using quote literals:

“a string with a quote ' ” → 'a string with a quote ' '

We can 1) normalize on the LARAC side and escape the quote or 2) identify the type of String (' or “) and generate code accordingly

*/

Should the joinpoint 'scope' be able to select its 'exit' points? This joinpoint would represent all the static exits that can be detected in the code (e.g., end of scope, return statements, throw statements).

Possible problems:

• When a scope does not explicitly return (equivalent to the $body.insert when $body is empty);
• We cannot detect dynamic exits such as exceptions (is this relevant?)
• When a return statement has computation (e.g., return a+2), the $exit.insert before does not have this computation into account (possible solution, LARA action that extracts computation from returns to a variable, e.g., lara_temp_1 = a + 2; return lara_temp_1;)

Joinpoint 'scope' is being used in Clava as the base joinpoint for the 'body' joinpoint. While $body.insert before/after conceptually inserts before/after the first/last statement of the body, when it is a 'scope' we want to be able to insert before/after it.

$scope.insert before/after inserts before/after the scope, as expected. Add two new actions, insertBegin and insertEnd, that behaves like $body.insert before/after.

If 'body' is also used as an alias of 'scope', for compatibility reasons, $body.insert before/after must continue to be supported. 'scope' can detect if it is being used as a 'body', and in case of insert before/after, issue a warning telling that insertBegin/End should be used instead.