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

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

On Thu, 20 Oct 2011 at 22:15 +0100, Arthur Norman wrote:

 > > 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.
 > > 
 > Indeed - but we could do it!

Yes - though a closer inspection shows that more functions in form.red need to 
be changed, formsetq among them.  In particular, nil is more work than t (or 
anything else).  For example, an empty statement

 ;

is parsed in the same way as

 nil;

(giving both no output in algebraic mode), and simply mapping nil to some 
internal identifier means that both statements will always print

nil

irregardless of the current mode.

As a first step, I corrected the bug reported in the SourceForge forum and added 
a couple of error checks for cases like using nil as a free variable in rules or 
trying to share t between algebraic and symbolic mode.

 > > Should we also allow t and nil as procedure and operator names?
 > If we map them (in algebraic mode only) onto internal names that do not clash
 > with Lisp then there should be no problem. And I can imagine people using "t"
 > as a function name.

Yes.  t as algebraic operator seems to work already.

 > > (BTW: The window version of CSL prints parentheses around "fluid t", the
 > > command
 > > line version does not.)
 > That is interesting. I will put in 90% of the way down my pile of things that
 > I might check one day.

Yes, that seems the right place for it ;-)

  Rainer