From: SourceForge.net <noreply@so...>  20071219 20:24:38

Bugs item #1854391, was opened at 20071219 15:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1854391&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: "if" doesn't give errors for nonbooleans Initial Comment: The following cases should give errors: if 3 then x$ if %pi then x$ if "hello" then x$ if [1] then x$ if matrix(...) then x$ if {1,2,3} then x$ (other cases?) because the constants or containers cannot evaluate to booleans regardless of the lexical environment. Perhaps the same should be true of expressions whose top level is an arithmetic operator, e.g. if x+1 then ... if 1/x then ... but I suppose the arithmetic operators could be overloaded (using pattern matching) to return boolean results in some cases. I ran into this problem when I mistakenly assumed that Maxima followed the Lisp convention that nonfalse was true: if assoc(x,'[["+",""],["*","//"]]) then ... when x was "+". Instead of getting an error message, I got an unevaluated conditional if "" then ... which made no sense at all. Maxima 5.12.0 GCL Windows  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1854391&group_id=4933 
From: SourceForge.net <noreply@so...>  20071229 19:21:09

Bugs item #1854391, was opened at 20071219 13:24 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1854391&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 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: "if" doesn't give errors for nonbooleans Initial Comment: The following cases should give errors: if 3 then x$ if %pi then x$ if "hello" then x$ if [1] then x$ if matrix(...) then x$ if {1,2,3} then x$ (other cases?) because the constants or containers cannot evaluate to booleans regardless of the lexical environment. Perhaps the same should be true of expressions whose top level is an arithmetic operator, e.g. if x+1 then ... if 1/x then ... but I suppose the arithmetic operators could be overloaded (using pattern matching) to return boolean results in some cases. I ran into this problem when I mistakenly assumed that Maxima followed the Lisp convention that nonfalse was true: if assoc(x,'[["+",""],["*","//"]]) then ... when x was "+". Instead of getting an error message, I got an unevaluated conditional if "" then ... which made no sense at all. Maxima 5.12.0 GCL Windows  >Comment By: Robert Dodier (robert_dodier) Date: 20071229 12:21 Message: Logged In: YES user_id=501686 Originator: NO >From what I can tell, the parser indeed looks to see if the first argument of "if" is a Boolean expression, but the test is weak  it only detects nonBoolean expressions for operators which are declared nonBoolean via the POS property. The parser's test appear to pass patently nonBoolean expressions such as numbers. e.g. prefix ("@@", 100, expr, expr); if @@ 1 then a else b; => Incorrect syntax: Found algebraic expression where logical expression expected Same result with other operators which have POS = $EXPR e.g.: + . ^ ^^ Maybe changing NUDCALL in src/nparse.lisp is enough. Here is the current version: (defun nudcall (op) (let ((tem (and (symbolp op) (getl op '(nud)))) res) (setq res (if (null tem) (if (operatorp op) (mreadsynerr "~A is not a prefix operator" (mopstrip op)) (cons '$any op)) (funcall (cadr tem) op))) res)) Here is a version which causes if 1234 then a else b; to trigger an error: (defun nudcall (op) (let ((tem (and (symbolp op) (getl op '(nud)))) res) (setq res (if (null tem) (if (operatorp op) (mreadsynerr "~A is not a prefix operator" (mopstrip op)) (if ($numberp op) (cons '$expr op) (cons '$any op))) ;; changed this line (funcall (cadr tem) op))) res)) Probably ($NUMBERP OP) should be something more complicated. We want to rule out numbers, strings, what else? Maybe objects such as matrices, lists, and sets?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1854391&group_id=4933 