#30 Comparison of attributes in match conditions need to be cast to the right type.

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?

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?

I can recommend aspirin or dafalgan/ibuprofen for your headache.

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.