Custom Query (1030 matches)

It seems the way ignore or ignorable declarations are implemented with defsetf doesn't make them entirely ignored, since a warning is still issued, and indeed, an uninterned symbol used in place of the parameter is still present and not declared anymore as ignored or ignorable.

(defgeneric bug (x y &optional z))

(defmethod bug ((x integer) y &optional z)
  (declare (ignorable z))
  (+ x y))

(defmethod bug ((x string) y &optional z)
  (list (aref x y) z))

(defun set-bug (x y new-value)
  (+ x y new-value))

(defsetf bug (x y &optional z) (new-value)
  (declare (ignorable z))
  `(set-bug ,x ,y ,new-value))

(defun f ()
  (setf (bug 42 0) 33))

(eval-when (:load-toplevel :execute)
  (pprint (swank-backend:macroexpand-all
           '(defun f ()
             (setf (bug 42 0) 33)))))


#|

dictionary> (load (compile-file  #P"~/ccl-bug.lisp"))

;Compiler warnings for "home:ccl-bug.lisp.newest" :
;   In f: Unused lexical variable #:z

(progn (ccl::%defun (ccl:nfunction f
                                   lambda
                                   nil
                                   (declare (ccl::global-function-name f))
                                   (block f
                                     (let* ((#:g90598 42) (#:g90597 0))
                                       (declare (ignorable #:g90598 #:g90597))
                                       (multiple-value-call
                                         (lambda (&optional #:g90596 &rest #:ignore)
                                           (declare (ignore #:ignore))
                                           ((lambda (#:x #:y &optional #:z) (set-bug #:x #:y #:g90596))
                                            #:g90598 #:g90597))
                                         33))))
                    'nil)
       'f)#P"/home/pjb/ccl-bug.lx64fsl"
|#

(loop named nil do (return 1)) does not establish a block at all instead of one named NIL, as I'd expect from 6.1.1.5.6: "The loop named construct gives a name for the block of the loop". There's no mention that specifying the name as NIL instead of defaulting to NIL through omission allows for the omission of the loop block.

Up-to-date linux, amdfam10, clozure 1.9 amd64 and ia32, both behave identically as far as this message is concerned. I don't know CL well, sorry, I'm just busting nil's irritatingly-anything-but-nihilistic chops.

  Welcome to Clozure Common Lisp Version 1.9-r15757  (LinuxX8664)!
  ? (defun nil () t)
  Lisp Breakpoint
  ? for help
  [15021] Clozure CL kernel debugger: 

  Welcome to Clozure Common Lisp Version 1.9-r15757  (LinuxX8664)!
  ? (defun t () nil)
  T
  ? (t)
  NIL

The former seems too harsh and the latter too lenient. Raising exception seems about right, though. This crap shouldn't work either...

  Welcome to Clozure Common Lisp Version 1.9-r15757  (LinuxX8664)!
  ? (setf (symbol-function nil) (lambda () t))
  #<Anonymous Function #x3020006F846F>
  ? (fboundp nil)
  #<Anonymous Function #x3020006F846F>
  ? (nil)
  > Error: NIL is not of type (OR SYMBOL FUNCTION), and can't be FUNCALLed or APPLYed
  > While executing: CCL::TOPLEVEL-EVAL, in process listener(1).
  > Type :POP to abort, :R for a list of available restarts.
  > Type :? for other options.
  1 > (symbolp nil)
  T
  1 > ;eof
  ? (funcall (symbol-function nil))
  T

But it didn't even do the wrong thing right, heh, (nil) raised an error.

This ticket-reporting thing didn't allow me to specify Version 1.9, only some milestone thing.

Regards, Andy Gaynor, euphoria@…