From: Arthur Norman <acn1@ca...>  20111020 18:43:17

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. 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 algebraiclevel 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. For e, i, pi and possibly MANY others the most I feel one could do would be to consider a warning message. But the "for i := 1:n" example is close to enough to persuade me that even that will hurt at least as many people as it helps. Arthur On Thu, 20 Oct 2011, Rainer Schöpf wrote: > The recent bug report > > https://sourceforge.net/tracker/?func=detail&atid=1126256&aid=3426364&group_id=248416 > > made me test how t and nil behave in algebraic mode. Try the following: > > algebraic procedure x(t); t; > algebraic procedure y(nil); nil; > algebraic procedure z(e);e; > x(1); > y(1); > z(1); > > CSL returns 1 in all cases, PSL replies with > > ***** T and NIL cannot be rebound > > in the first two. > > I think the use of reserved identifiers as formal parameters or free variables > in a rule should lead to an error. > > Rainer > >  > The demand for IT networking professionals continues to grow, and the > demand for specialized networking skills is growing even more rapidly. > Take a complimentary Learning@... SelfAssessment and learn > about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/ciscodev2dev > _______________________________________________ > Reducealgebradevelopers mailing list > Reducealgebradevelopers@... > https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers > 