Project

General

Profile

Bug #94

Default reason for protected variables

Added by John Abbott about 12 years ago. Updated about 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
John Abbott
Category:
Parser/Interpreter
Target version:
CoCoA-5.1.0 Easter14
Start date:
29 Feb 2012
Due date:
% Done:

100%

Estimated time:
3.00 h
Spent time:
2.95 h

Description

Attempting to set a variable which has been protect-ed without an explicit reason produces an unsatisfactory error message:

ERROR: Cannot set "N" (no reason given)

Expressed this way, it seems that CoCoA-5 itself is unable to determine the reason.
I suggest a better default message for the reason, e.g. variable protected by user

I recall the syntax for giving a reason: Protect N: "reason";
The resulting error message will then look like:

ERROR: Cannot set "N" because "reason"

I observe also that the formats of the error messages are slightly different: one puts the reason in brackets, the other inserts the word because. JAA has a mild preference for more consistency in the formats. What do you think?

Related issues

Related to CoCoA-5 - Bug #102: Packages: should exported functions be automatically "Protect"ed?Closed2012-03-09

Related to CoCoA-5 - Feature #531: Package protected variables should know which package protected themClosed2014-04-09

History

#1 Updated by John Abbott about 12 years ago

I suggest the following format for the error message:

ERROR: Cannot set "N" -- reason

The suggested changes are:
  • replace the word because by a double minus
  • no double quotes around the reason
  • the default reason is variable protected by user

Grammatically a colon would be better than the double minus, but I think it may look odd (I'll try).

#2 Updated by John Abbott about 12 years ago

  • % Done changed from 0 to 10
  • Estimated time set to 3.00 h

After trying some possibilities, my preference is now for the reason to appear in brackets, like this:

ZZ:=0;
ERROR: Cannot set "ZZ" (it is a system-protected variable)
A:=0;
ERROR: Cannot set "A" (variable protected by user)

I'm not yet sure what the best "template" is for general reasons; my current suggestion is

ERROR: Cannot set "A" (variable protected by XXX)

So the "reason" is regarded as identifying who applied the protection (rather than why it was applied).

I was thinking of a template reason being variable protected by package YYY.
Another reason could be variable protected by Define command.

Once we have decided what to do, the implementation should be very quick. Testing might take some time though.

#3 Updated by Anna Maria Bigatti over 11 years ago

  • Category set to Parser/Interpreter

#4 Updated by John Abbott about 10 years ago

I'd like to resolve & close this issue in the near future!

#5 Updated by Anna Maria Bigatti about 10 years ago

  • Target version set to CoCoA-5.1.0 Easter14

#6 Updated by John Abbott about 10 years ago

  • Status changed from New to Feedback
  • Assignee set to John Abbott
  • % Done changed from 10 to 90

I have implemented the suggestion in comment-2.

Changing status to feedback.

#7 Updated by John Abbott about 10 years ago

  • Status changed from Feedback to Closed
  • % Done changed from 90 to 100

Closing after interactive testing with Anna. Made some minor variations on the suggestions in comment-2.

Test cases:
assign to user-protected variable (user gave no special reason)
assign to user protected variable (user did give a special reason)
reprotect user-protected variable (user gave no special reason)
reprotect user-protected variable (user did give a special reason)

Also checked system protected variables (e.g. ZZ and loop variables),
an package-exported variables (e.g. HilbertFn)

Also available in: Atom PDF