gama.old icon indicating copy to clipboard operation
gama.old copied to clipboard

Renaming of a temp variable in a block will rename others in other blocks with same name

Open pcaillou opened this issue 10 years ago • 4 comments
trafficstars

What steps will reproduce the problem?
1. Run attached file
2. Try to rename mapReturnValue


What is the expected output? What do you see instead?
- Expected output: only mapReturnValue of the method using will be renamed.
- Instead: mapReturnValue  of both method will be renamed.


If i add mapReturnValue to species (i.e move to species variable space, not action
variable space), the rename do "kind of correct" meaning, but break the meaning (i.e:
I want to rename variable at action level, not species level, due to shadowing variable
name).


What version of the product are you using? On what operating system?
- V1.6.1, @Windows 8.1

Please provide any additional information below.

Original issue reported on code.google.com by tranbach93 on 2015-01-22 06:59:08


- _Attachment: [temp.gaml](https://storage.googleapis.com/google-code-attachments/gama-platform/issue-1160/comment-0/temp.gaml)_

pcaillou avatar May 31 '15 20:05 pcaillou

Note: It also happened when rename other types of variable, not only [map].

Original issue reported on code.google.com by tranbach93 on 2015-01-22 20:17:43


- _Attachment: Screen Shot 2015-01-23 at 3.16.51 AM.png
![Screen Shot 2015-01-23 at 3.16.51 AM.png](https://storage.googleapis.com/google-code-attachments/gama-platform/issue-1160/comment-1/Screen Shot 2015-01-23 at 3.16.51 AM.png)_

pcaillou avatar May 31 '15 20:05 pcaillou

Acknowledged and reproducible. The XText linker seems to have a hard time figuring out
the contexts of the variables (which is computed later in the compilation process).


Will see what I can do about it, but do not expect rapid progresses… 

Original issue reported on code.google.com by alexis.drogoul on 2015-01-23 02:11:07

  • Labels added: GAML, Version-All, OpSys-All, Milestone-1.7

pcaillou avatar May 31 '15 20:05 pcaillou

This issue is linked with the way the default IReferenceFinder is implemented in XText.
Instead of progressing from the inner to the outer scopes, it does the reverse on the
whole document. It makes sense when the reference to variables, etc. is computed using
hierarchical qualified names (i.e. the "internal" name of a variable is the composition
of the name of the blocks in which it is declared + its own name), but it is not (yet)
the case in GAML, as we have to deal with multiple contexts of declaration (inheritance,
macro-species, skill, etc.) which are too complex and probably too costly to track
during the syntactic validation of models (they are tracked later, during the semantic
validation, the result of which is not available for operations like finding references
+ renaming). 

I will try to find a way to inject some basic semantic knowledge in this process, by
:

(1) progressing from the inner to the outer block when the target (i.e. the highlighted
name) is not a definition but the use of a variable and stopping at the first definition
encountered.

(2) progressing from the outer to the inner scope when the target is part of a definition,
and stopping (i.e. not exploring within the block) whenever a similar definition is
found in a block.

(3) find a way to follow the definition contexts when using the '.' operator on a variable
(i.e. this use can be in a completely different block, so we have to extract the species
of the agent to which ".' is applied, not always easy. 

(4) find a way to follow the definition contexts when the variables are used in a "remote
context" block (the ones that follow ask / create statements). Again, the target species
has to be found and it is not easy to do without a complete semantic validation of
the model. 

The two last operations are the most complicated to implement, since they require that
a whole part of the current semantic validation be performed during the so-called syntactic
phase (ie. before IDescription objects are created). 

Original issue reported on code.google.com by alexis.drogoul on 2015-05-21 03:40:45

  • Labels added: Priority-Critical
  • Labels removed: Priority-Low

pcaillou avatar May 31 '15 20:05 pcaillou

I think this issue will not be addressable in time for GAMA 1.7, as it requires quite critical changes in the grammar and the syntactic validation/scoping of GAMA.

AlexisDrogoul avatar Dec 19 '15 16:12 AlexisDrogoul