[vw78] nil temp

Greetings Steve and Herr Haider,

Steve: I revised Resolution 99657 with the official change that removes the nil from the method that is fixed by the Resolution. A CD that includes that revised Resolution was sent to you last week. You should be receiving it soon.

Herr Haider: Or records indicate that you were recently sent a copy of VisualWorks 7.8. Would you like us to send you a CD with this Resolution, or would you like us to send you one of all our accumulated Resolutions CDs?

-----Original Message-----
From: Steven Kelly [mailto:[hidden email]]
Sent: Thursday, May 12, 2011 6:27 AM
To: Christian Haider; [hidden email]
Cc: Savidge, James
Subject: RE: [vwnc] [vw78] nil temp

Yep, I reported that too! It’s harmless, but reveals a bug in the parser. Here’s what I sent to James Savidge at Cincom (in connection with the mask printing AR 41293 / Res 99657) about the ‘nil’ temp variable – I don’t know if an AR has been created for this parser problem:

Checking the bytecode shows that variable isn’t used – occurrences of “nil” in the body of the method are compiled as references to the nil object, rather than the temporary variable’s value.

Perhaps it’s worth having an AR on what can be a legal temp name? Having nil in the list breaks the RB refactoring

commands. I can’t select it (or indeed any other variable in that method) and choose Refactor | Rename Variable As…. If I remove it, all is OK again (there are warnings about xStart, but that’s expected).

If I add nil back, I am told that the variable nil is unused, but I can ignore that and accept anyway.

If I then add a first line “nil := 0”, I get an error LiteralNode DNU #name, in BlockAnalyzer.

I guess it would be best to say nil cannot be used as a variable name. The pseudovariables self, super and thisContext already say that. Reserved words true and false behave similarly to nil when used as variable names, so they should be disallowed too.

Cheers,

Steve