excessive persistence of location constituents

[grammarware]

There are some actions you can perform on a loc variable which makes it point to an entirely different file — like appending a string to it or doing .parent (possibly many others, these two were just the source of the bug in my Rascal program that we spent some time catching this week). However, as it is now, these actions inherit offset and all the other trailing things from the original location.

As a result, you can have situations when you have constructed a new location in your code to point to something like another file in the same folder, but if you do readFile on it, it will read whatever the selected span was in the original file, which makes no sense. Fixing it with .top is easy, but catching and debugging is not, especially if you have something that must run across several OSs and entry points. Besides, it's probably not the semantics you want anyway.

I still have the push rights and am willing to adjust this (especially if pointed towards the modules which cover it), just didn't feel comfortable doing it without proper explicit discussion. This change would not be backward compatible. Yet, it is hard to think of code that was written in good conscience which would be harmed by this.

Let me know what you think.

[jurgenvinju]

Hi Vadim. Thanks for the clear analysis. I agree that position information should better be removed for the operations that change the URI.

A different resource will hardly ever have comparable offsets and if that is the case the Rascal programmer could easily propagate them programmatically.

So let's change the default behavior. My 2 cents.

[jurgenvinju]

This will require some analysis in important applications of Rascal because of the backward incompatibility. So let's see about that first.

[jurgenvinju]

• scheme changes should probably keep the location information. Chances are that it is the same file but in a different state (inside a jar)
• authority same same, a file copied to another system is still the same file inside.
• path, query and fragment all identify different files or different contents or parts of the same file. So here we could drop the positions if these change.

[DavyLandman]

I've been hit by this bug as well, however I think we have to be careful. I suggest only the following operations would drop the positions:

• .parent
• .path
• .extension
• loc + str

Even still I'm a bit hesitant of this change, for example if you use relativize function to get source path specific locations, you might not want to loose the positional data?

[jurgenvinju]

Those operations coincide with the field changes mentioned earlier, but there are more operations that use the same fields. Also this semantics would happen deeper under the hood where we have only field names, not what is happening to them. So let's focus on the fields rather than the functions and operations.

Nevertheless, for every library function which changes path, query or fragment or rascal operation, we should then review whether or not to put the positions back.

For example, for relativize this would seem natural since even though the path changed and the scheme, we are still indicating the same file semantically.

For extension we wouldn't put it back. Etc. Etc. It is going to be a long list but not a complex task. The question is always: does the new location logically point to the same resource? If yes, then carry over over positions, otherwise do nothing.

[jurgenvinju]

We should also consider that the position information actually belongs in the fragment part, and what would happen if/when we move the notation in that direction.

Consider that for actual fragments the same question holds: if we change the path but not the fragment, is the fragment still valid? I put forward the the answer is the same as for our positions.

[DavyLandman]

For extension we wouldn't put it back. Etc. Etc. It is going to be a long list but not a complex task. The question is always: does the new location logically point to the same resource? If yes, then carry over over positions, otherwise do nothing.

I'm unsure if we can get this right at the rascal operation level. For example the relativize function changes path and still points to the same file, while .parent changes the path but doesn't point to the same file. We cannot always resolve locations to the file, for example the relative paths cannot be resolved without a context.