Re: [Reduce-algebra-developers] Use of t and nil in Reduce

[Rainer S. <rai...@gm...>]

On Thu, 20 Oct 2011 at 19:43 +0100, Arthur Norman wrote:

 > If you switch "on comp" so that CSL compiles things I believe you will see
 > diagnostics (albeit not very nice ones) from your first two cases.
 > At the Lisp level it can not make sense to refuse to allow "e", "i" etc to be
 > local variables, or else
 >   for i := 1:n do ...
 > would be rejected and MANY people would be upset.

Yes, I didn't think of that.  

 > The symbols "nil" and "t" have special historical meanings at the level of
 > symbolic (lisp level) code and maybe for them "form" and friends could rename
 > them to something anodyne if seen in algebraic-level code so that for
 > ordinary algebraic users they would not be reserved any more. That MAY be as
 > easy as addint to the algid procedure in rlisp/form.red
 >   if u = nil then 'algebraic!:nil
 >   else if u = t then 'algebraic!:t
 >   else whatever it had before
 > and in a matching way arranging that printing new to map the internal names
 > back to what they were on input.

Agreed, though redefining algid isn't enough: it is not applied to procedure 
parameters, local variables or free variables in rules. Ie. formblock, formproc 
and forall need to be changed as well.

Printing t is easy, just add

 put('algebraic!-t,'oldnam,'t);

but this doesn't work for nil, as after

 put('algebraic!-nil,'oldnam,'nil);

get('algebraic!-nil,'oldnam) 

still returns nil.

Should we also allow t and nil as procedure and operator names?  At the moment 
nil doesn't work at all, and t cannot be a procedure in CSL:

procedure t(x);x;

***** fluid t invalid as procedure

(BTW: The window version of CSL prints parentheses around "fluid t", the command 
line version does not.)

No problem with disallowing both, but CSL and PSL should behave in the same way, 
with a slightly better error message like

***** reserved identifier t invalid as procedure

  Rainer