AToMPM / atompm

A Tool for Multi-Paradigm Modeling
https://atompm.github.io/
GNU Lesser General Public License v3.0
22 stars 15 forks source link

Comparison of attributes in match conditions should be cast to the right type. #22

Open BentleyJOakes opened 6 years ago

BentleyJOakes commented 6 years ago

opened 10 months ago by claudio

Claudio

Currently, in the match conditions, attributes need to be converted to the right type before being used. For example, the following match code will go nuts

`result = getAttr('watch','0') + getAttr('time2Move','0') == getAttr('after','3')'

Because it stores the attributes as strings, and getAttr returns these as strings, even though the original metamodel explicitly declares them as integers.

This causes a great deal of headaches while making model transformations.

Can they not be returned with the right type? If that is too hard to implement, is there a way the headaches can be mitigated?

Simon

Claudio, I don't know what strange version of AToMPM you're running, but I can assure you that integers are returned as integers. They are decidedly not stored as strings. Same goes for other types, such as lists, dicts, booleans, and the like.

Now, it is possible to store string values in integer attributes by writing faulty action code that computes a string instead of an integer. This, of course, should not be allowed, and you're free to write type checks in the model transformation back-end. Might I suggest you check that your action code always computes integer values for integer attributes?

Claudio

Hmm ok. I will assume that you are correct.

Now, please do not dismiss my comments immediately, since they may hide a deeper problem. I did not spend the time to document these issues out of pleasure...

Assuming that you are correct, then there are at least two possible culprits:

  1. Faulty action code that stores the attributes with a different type, as you said.
  2. Faulty default values (an example is in /Formalisms/Pacman/PacmanMM.model, type Food, whose default value is "1" (a string)).

In either of these two cases, there should be a check to make sure that the value being stored (I suspect the setAttr function is being used in each of these cases) is of the declared type. Is this something that cannot be implemented easily?

I think the benefit would be tremendous, because it is all too easy for a new user to make these mistakes. In the second case, you can even see what it lead to if you open the RHS of /Formalisms/Pacman/OpSem/PacEat, and you see this code:

`setAttr("score", getAttr("score", "3") + int(getAttr("points", "4")), "3")'

This can be avoided by simple checks in the code.

BentleyJOakes commented 3 years ago

Also to be investigated is the setting of boolean attributes.

As reported:

from random import choice
c = choice ( [ ”3” , ”4” ] )
# Set the activated attribute of the randomly selected connection to False.
# To set a boolean to False we need to pass an empty string as value.
setAttr ( ”activated ” , ”” , c )