Project

General

Profile

Design #997

Using protected variable names for "bound variables" (e.g. for, try...endtry)

Added by John Abbott over 7 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
John Abbott
Category:
Parser/Interpreter
Target version:
CoCoA-5.3.0
Start date:
18 Jan 2017
Due date:
% Done:

100%

Estimated time:
0.99 h
Spent time:
0.95 h

Description

I was surprised the following did not produce any error about protected variables:

for QQ := 1 to 5 do println QQ endfor;
try 1+2 uponerror QQ do println QQ endtry;
try 1/0 uponerror QQ do println QQ endtry;

Is it worth trying to fix this?

Related issues

Related to CoCoA-5 - Feature #1003: New syntax for creating poly rings?In Progress2017-01-27

History

#1 Updated by John Abbott over 7 years ago

The following example does nothing embarrassing:

define fn(a) TopLevel QQ; return RingElem(QQ,a); enddefine;
for QQ := 1 to 5 do println fn(QQ); endfor;

The point is that TopLevel does retrieve the correct variable QQ (namely the protected one containing the field of rationals).

#2 Updated by John Abbott over 7 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

I note also that "protected names" are allowed as formal parameters for user defined fns: e.g. the following works fine

define add1(QQ) return QQ+1; enddefine;

The important point is that a name may refer to different variables in different contexts, and it is the variable which is protected (rather than the name).

Top-level names are just variables assigned to at top level (and some system protected ones), and names "assigned to" by the define command.

Perhaps the best action would be just to make sure that this is clear (somewhere) in the documentation.

#3 Updated by Anna Maria Bigatti about 7 years ago

This, not surprisingly, doesn't work ;-)

Define FunnyFunc(GBasis)
  return GBasis(ideal(GBasis));
EndDefine;

Even though surprinsing this is not seriously ambiguous or dangerous.

#4 Updated by John Abbott about 7 years ago

The following works:

P ::= QQ[QQ];
-- use PP; --> gives error (phew!) because QQ is protected
qq := indet(P,1);
qq; --> prints "QQ" obviously!

Boggle!

#5 Updated by John Abbott about 7 years ago

Think about the following valid CoCoA-5 code:

P := NewPolyRing(QQ, "define, func, enddefine");
use P;  --> yes, this works!  8-O

This creates toplevel variables whose names are the same as keywords; there is no way to access the values of these variables!

#6 Updated by John Abbott about 7 years ago

  • Related to Feature #1003: New syntax for creating poly rings? added

#7 Updated by John Abbott about 4 years ago

  • Assignee set to John Abbott
  • Target version changed from CoCoA-5.?.? to CoCoA-5.3.0
  • % Done changed from 10 to 50

I had forgotten about this "entertaining" issue.

I do not really see anything "dangerous" here; the only slightly surprising fact is that the variable of a top-level for loop is not itself a top-level variable.

I am inclined to close this issue. Agreed?

#8 Updated by John Abbott about 4 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 50 to 100
  • Estimated time set to 0.99 h

Anna agrees with the proposal to close this issue.

The problems highlighted here are easy to work around (and you have to be a vandal to encounter them anyway ;-)

Also available in: Atom PDF