3 ms·
Damned Common Lisp! CL-USER> 20 / 5
- kazinator 5y agoHmm, that listener seems to have ignored the first two expressions of 20 / 5 and just printed information about 5. If it did evaluate /, it would have worked because / has a variable binding in the Common Lisp listener. http://www.lispworks.com/documentation/HyperSpec/Body/v_sl_sls.htm#SLSLSL http://www.lispworks.com/documentation/HyperSpec/Body/v_sl_s... The variable / refers to the list of values which came from the most recent Listener evaluation. // refers to the previous one, and /// to the one before that. Funny coincidence; I just fixed a related issue in TXR 264, released today. This is the TXR Lisp interactive listener of TXR 263. Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet. Reminder: your account balance of 37 closing parentheses is past due. 1> 20 / 5 20 The first expression is extracted; trailing stuff is ignored. This is the TXR Lisp interactive listener of TXR 264. Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet. TXR is tested on nothing but animals (so to speak). 1> 20 / 5 expr-1:1: trailing material after expression ** syntax error: read: expr-1: errors encountered A user reported doing: txr -e '(defun foo () ...) (foo)` from the system prompt, and was surprised that the function wasn't doing anything, which is because `(foo)` is never evaluated. Silently doing some wrong/unexpected thing is the bane of software. Some things you don't run into by yourself; stuffing in two or more expressions where I know one is expected is something I just wouldn't run into myself.