detect variable shadowing issues

Is it possible to detect in Singular the following issue and warn the user?



bughunter

Cannot be done in a sensible/reasonable way because of dynamic scopes of names
- ideas from static scopes (like in C) do not apply.
Example where we do not want a warning:

Example where a decision about a warning is impossible

and so on...
The precedence rules are not fool-proof but allow to solve these issues.

a naive question (I do not understand yet how the Singular interpreter works):
is it not possible to remove all variables tied to r1 from current scope before the ring change
from r1 to r2 ? Then there would be no warning?


I would not want to warn at line 'int x',
but at 'setring r1' line.

My intention would be not to help the user to write safe code (which seems impossible without changes to interpreter)
but just to warn that there might be a mistake.

And the only safe way seems (?) not to import ring variables to current scope but access them only like

or or similar.

So a proposal would be to update all library code to usage of var(), par(), ringlist or
r1.x and so on , warn during the transition time the user if possible and when finished,
refrain from exporting ring variables to current scope?

Assuming that this reply was not a bad joke:
- "is it not possible to remove all variables tied to r1 from current scope before the ring change from r1 to r2 ?"

This is the way it works: otherwise

int x,y;
ring r=integer,(x,y),dp;

would not have 2 generators.

- " would not want to warn at line 'int x',
but at 'setring r1' line."
but the conflict/mistake is at "int x": setring introduces no new variables.

- Addressing variables as "var(i)" is already possible.
(The form r1.x would introduce other problems: what is r1.x+r2.y?)
Or do you propose to use ONLY that form?
Remember that the user (FYI: a human being) had type that in: and
tab-expansion does not help here. And it would break compatibility with
older versions, with other programs, and with common sense.

- Or do you propose to use a different language for libraries than for the user
input? That is already possible, but we use C/C++ as that language.
Quite useful for special purpose but generally discouraged.
Would require to rewrite ~300 000 lines of code (the existing libraries) and
would double the amount of tests (test 2 interpreters instead of one).

True, but I still propose (to be discussed) to optionally warn here,
because a simple-minded developer or user would spuriously expect that x refers to a ring variable:

> int x;
...
... tons of other code
...
> ring rng = 0,(x,y),dp;
> x+y;
y // => a baffled user or developer



Initially, an error.

Currently I do not propose to use _only_ that form.

I will be happy if we _find_ a proposal at all on which we agree and which solves the problems of silent bugs
related to variable shadowing

No

ok, good to know. So here is another probably naive or dumb question:

Is it possible to check for variable conflicts between the full variable scope and variables tied to r2
just _after_ all variables tied to r1 were removed from current scope?

> int x;
> ring r1 = 0, y, dp;
> ring r2 = 0,(x,y),dp; // expect a warning for conflict of 'x'

i suppose one would never write "poly p = p;" unless it happens due to execute. therefore never use execute!

the problem happens since the Interprer virtually rewrites

into


Due to performance reasons the assigment has no idea whether NAME was declared just now or not.

Therefore it is thechnically possible to catch such issues but that will result in performance loss.
Moreover such a change is rather complicated to implement (i think at least a change of grammer will be necessary for that).

Regards,
O.

I agree with malex. There are times in which I wish Singular would have a list of names that I am not allowed to use (for objects and for variables) and give an explicit error if I try to use one of the forbidden names (most of the times I'm trying to introduce a variable called "test" while debugging my code), but the work to realize that far outweigh the gain.

There are various promising projects involving alternative interpreters for Singular, perhaps one of them will solve this issue in the long run...? In the meantime, let's trust the users that they know what they are doing when using "execute". Sometimes, it is sadly just not possible to get around that.

What do you suggest? Do nothing is not an option (for me).


Sadly, we can't trust the users or developers, and meanwhile many unsafe code statements are part of the library code.
And, as shown in the initial example, it is not necessary to use 'execute' to hit this bug.
So if we continue without a change, things will became much worse over time (and they did).
And of course a change may feel strange, that is normal.

So should we ignore the problem because it is easier? I won't.

@hannes
I agree on this with you.

That is already there:

helps with reserved names, for the currently used names, use: