Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Rainer Schöpf <rainer.schoepf@gm...>  20111020 17:27:30

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 
From: Rainer Schöpf <rainer.schoepf@gm...>  20111020 17:27:30

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 
From: Rainer Schöpf <rainer.schoepf@gm...>  20111020 17:30:39

Addendum: For real fun, try operator fun; for all nil let fun(nil)=nil; Rainer 
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 > 
From: Rainer Schöpf <rainer.schoepf@gm...>  20111020 20:43:19

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 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. 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 
From: Arthur Norman <acn1@ca...>  20111020 21:15:43

> 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! > 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. I can only see 3 places in the sources where oldnam is inspected: in math/mprint.red, rprint/rprint.red and utf8/utf8.red so putting an explicit test in each of those for the mapped version of "nil" might be ugly but is not a huge risk maybe. Is at least protecting nil and t this way worth it? I suspect so... > > 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. > 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 This is because in CSL "t" is marked as a fluid variable and then the rlisp parser sees that as a type and moans. It appears that PSL treats "t" as so special that although it has a global (fixed) meaning it is neither fluid nor global, hence Reduce does not know to complain. Now whether being the name of a global or fluid variable should cause a refusal to allow something as a function name is another thought. The code that provoked the error will prevent names of matrices etc being used as procedure names. And back in the days when some Lisps had values and functions in the same cell one wanted this check. > (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. > > 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 > For "t" we possibly want special treatment for nil and t in symbolic mode, but I suspect I vote for internal renaming that means they become "not at all special" in algebraic mode... > Rainer > 
From: Rainer Schöpf <rainer.schoepf@gm...>  20111021 16:38:58

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 
From: Rainer Schöpf <rainer.schoepf@gm...>  20111023 19:42:54

It turns out that mapping external to internal identifiers isn't so simple. A fair number of the user contributed packages need to be changed to work with it, because they define their own statement parsing or because they do clever things with identifiers like explode/compress or mkid. So, I checked in a workaround for the original bug with t as a free variable in rules and a regression test for various valid or invalid uses of t and nil. Rainer 