MantisBT - Core Inform
View Issue Details
0001092Core InformPhrases and functional programmingpublic2013-03-30 10:472014-05-07 07:33
(cosmetic) Error message is badly worded
0001092: Limit of 15 local variables is obsolete
The problem message here says:

"...there are too many temporarily-named values in this phrase, which may be a sign that it is complicated enough to need breaking up into smaller phrases making use of each other. For reasons to do with the construction of IF story files, there can never be more than 15 temporary values at a time..."

This is true of the Z-machine, but Glulx accepts up to 31, and that limit can be raised arbitrarily with a declaration like "Use MAX_LOCAL_VARIABLES of 64."

The problem message goes on to recommend keeping phrases simple. I agree, but this is a stylistic question and not something the compiler needs to enforce.

(There are extensions which attempt to replace the core parser, which is perhaps hubris but also admirable -- Ron Newcomb succeeded at it. I don't know if he used a lot of local variables, but I wouldn't blame him if he wanted to! This issue came up again when someone began trying to write a Japanese parser routine: see [^] )

I am filing this as "badly worded error message", because at minimum it is that. But please take it as a back-door feature request. :)
The Kitchen is a room.

To zork:
let x1 be 1;
let x2 be 2;
let x3 be 3;
let x4 be 4;
let x5 be 5;
let x6 be 6;
let x7 be 7;
let x8 be 8;
let x9 be 9;
let x10 be 10;
let x11 be 11;
let x12 be 12;
let x13 be 13;
let x14 be 14;
let x15 be 15;
let x16 be 16;
No tags attached.
Issue History
2013-03-30 10:47zarfNew Issue
2013-03-30 13:09EmacsUserSeveritymild => cosmetic
2013-03-30 13:09EmacsUserStatusnew => confirmed
2014-01-25 01:41grahamNote Added: 0002348
2014-01-25 01:41grahamStatusconfirmed => resolved
2014-01-25 01:41grahamResolutionopen => fixed
2014-01-25 01:41grahamAssigned To => graham
2014-05-07 07:32jmcgrewFixed in Version => 6L02
2014-05-07 07:33jmcgrewStatusresolved => closed

2014-01-25 01:41   
I've raised the limit to 256 when I7 compiles to Glulx, and rephrased the problem message. I agree, in principle, there shouldn't be a limit, but it's a nuisance internally to allow for this, and honestly 256 seems like enough of a ceiling for now.