From: SourceForge.net <no...@so...> - 2006-07-04 17:56:56
|
Bugs item #711472, was opened at 2003-03-28 10:59 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=711472&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Strings mishandled in constantp, orderlessp, comparison Initial Comment: Most parts of Maxima incorrectly treat Maxima strings (e.g. "foo") as variables, not as manifest constants. This is understandable, since they are represented internally as Lisp symbols, but is still incorrect. A few places get it right. For example, setting a string to a value ("f":3) gives an error. But note that mset doesn't even use the standard mstringp predicate.... In many places, the problem with strings is simply that illegal operations don't give errors, e.g. depends("f",g). But in other places, meaningful operations give incorrect answers: constantp("foo") => false BAD This is easy to fix, and the runtime overhead shouldn't be an issue nowadays. Though perhaps it would be better to give string symbols an explicit plist property. orderlessp(foo,"foo") => true, though the convention is that all manifest constants come before variables. Cf. sort([2,%pi,foo,"foo"]) => [2,%PI,foo,"foo"] Probably the biggest problematic area is in comparisons. Since string comparisons don't work, strings become pretty useless in Maxima programming. The following comparisons give errors: is("a"<"b") is("a"<="b") is("a" # "b") is(equal("a","b")) Though the following predicates work correctly: is("a"="a") => true is("a"="b") => false is("a" # "a") => false is("a" # "b") => true is("a"<="a") => true is(equal("a","a")) => true Not by coincidence, the correct cases are those where the rules for variables give the correct result.... Of course, it would be better to convert Maxima strings to use Lisp strings, but in the meantime.... Note, by the way, that Maxima DOES depend on the fact that strings are interned to do things like put the OPR property on &+. But this can of course be fixed. Maxima 5.9.0 GCL 2.5.0 mingw32 Windows 2000 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=711472&group_id=4933 |