[Openmcl-devel] Compiler warnings

[james anderson]

On 2009-10-21, at 12:08 , Tim Bradshaw wrote:

> On 21 Oct 2009, at 09:52, Tobias C. Rittweiler wrote:
>
>> As the consequences are undefined, implementations may conformingly
>> grab for means outside the standard.
>
> I think this is a really important point (I was half-way through a
> message saying the same thing, but not so well).
>
> It is clear that the standard for CL is not meant to be complete, in
> the sense that a conforming implementation may have extensions to the
> standard.  For instance, a conforming implementation may define a
> foreign function interface, or may have an object system which is not
> CLOS (so long as it also has CLOS), or a MOP for CLOS.  Or it may have
> global lexicals, or all sorts of special top-level behaviours[*].
>
> This is obvious, but there seems to be a trend for people to say
> "because feature x is not in the standard, implementations may not
> provide it".  This is really only true where the standard *prohibits*
> feature x, which may be because it directly conflicts with features
> provided by the standard, because the standard just says "you may not
> do x", because the feature would break conforming programs, or
> possibly for other reasons.

you treat the notion of conformance too loosely for it to be useful.  
i don't buy the argument.

yes, if someone puts "global lexicals" on my plate, if i would  
otherwise starve, i will eat them.
but, i will not pay for them.
and, i will feel justified to walk into the kitchen and interfere  
with the chef de cuisine and ask whether, despite how liberating his  
notion of a "free variable" may be, whether it still leaves me in a  
position to write a conforming program. that is, one which (by  
definition) depends "only upon documented aspects of common lisp".

the documented behavior of setf/setq permits (the names of) lexical  
variables and dynamic variables. these two classes include none of
- "free variable" - a concept which, as seductive as it may be,  
suffers the contradiction, that the "free" variable is created by a  
binding.
- "global lexical variable" - which, in any event, is contradicted by  
the extant implementations.
- "non-special dynamic variable" - which, in any event, is an empty set.
- "indefinite variables" - which, despite being the closest  
denomination, does not appear in the spec

as it happens, if i do depend on this undocumented behavior, as  
circumstances have it, my non-conformant program is still portable.


(in-package :cl-user)

(setq *load-print* t)

(unintern 'var)

(defparameter *level* 0)

#+sbcl (unlock-package :sb-debug)
#+cmu (setq ext:*top-level-auto-declare* nil)

(setq var 10)

(defun fun1 () var)

(defun fun2 (var) var)

(defun fun3 () (lambda () var))

(defun fun4 (var) (lambda () var))

(defun fun5 (var) (declare (special var)) (lambda () var))

(defun fun6 (&optional (var var))
   (declare (special var))
   (decf var)
   (if (plusp var) (1+ (fun6 )) 0))

(defun fun7 (&optional (var var))
   (decf var)
   #| cmucl 19e runs off into oblivion above 3000000 |#
   (when (> (incf *level*) 1000000) (error "too many levels"))
   (if (plusp var) (1+ (fun7 )) 0))


(pprint (mapcar
  #'(lambda (form)
      (let ((op (compile nil `(lambda () ,form))))
        (format t "~&~s => " form)
        (prin1
         (handler-case (funcall op)
           #+allegro (excl::SYNCHRONOUS-OPERATING-SYSTEM-SIGNAL (c) c)
           #+ccl (ccl::stack-overflow-condition (c) c)
           #+cmu (error (c) c)
           #+sbcl (SB-KERNEL::CONTROL-STACK-EXHAUSTED (c) c)))))
  '((lisp-implementation-version)
    (fun1)
    (fun2 0)
    (funcall (fun3))
    (funcall (fun4 100))
    (funcall (fun5 100))
    (fun6 )
    (fun7 )
    (list var (let ((var -1)) (list (funcall (fun3)) var)))
    (list var (let ((var -1)) (declare (special var)) (list (funcall  
(fun3)) var)))
    (list var (let ((var -1)) (list (funcall (fun4 -2)) var)))
    (list var (let ((var -1)) (declare (special var)) (list (funcall  
(fun4 -2)) var)))
    (list var (let ((var -1)) (list (funcall (fun5 -3)) var)))
    (list var (let ((var -1)) (declare (special var)) (list (funcall  
(fun5 -3)) var))))))

:EOF


#|
  allegro :
   ("8.1 [Mac OS X] (May 6, 2009 10:09)"
    10 0 10 100 10 9 #<SYNCHRONOUS-OPERATING-SYSTEM-SIGNAL @  
#x11779c6a> (10 (10 -1)) (10 (-1 -1)) (10 (-2 -1)) (10 (-2 -1)) (10  
(10 -1)) (10 (-1 -1)))

  mcl :
   ("Version 5.2b6"
    10 0 10 100 10 9 #<CCL::STACK-OVERFLOW-CONDITION #x3736AB6> (10  
(10 -1)) (10 (-1 -1)) (10 (-2 -1)) (10 (-2 -1)) (10 (10 -1)) (10 (-1  
-1)))

  sbcl :
  ("1.0.2"
   10 0 10 100 10 9 #<SB-KERNEL::CONTROL-STACK-EXHAUSTED {11FD9881}>  
(10 (10 -1)) (10 (-1 -1)) (10 (-2 -1)) (10 (-2 -1)) (10 (10 -1)) (10  
(-1 -1)))

  cmucl :
  ("19f (19F)"
   10 0 10 100 10 9 #<SIMPLE-ERROR {405F7135}> (10 (10 -1)) (10 (-1  
-1)) (10 (-2 -1)) (10 (-2 -1)) (10 (10 -1)) (10 (-1 -1)))

  ccl :
  ("Version 1.3-RC1-r11719M  (DarwinPPC32)"
   10 0 10 100 10 9 #<CCL::STACK-OVERFLOW-CONDITION #x8583DE6> (10  
(10 -1)) (10 (-1 -1)) (10 (-2 -1)) (10 (-2 -1)) (10 (10 -1)) (10 (-1  
-1)))

|#

as said, i do have enough faith in the chef that i will eat what he  
puts on my plate, and either i am just lucky, or those behaviors  
covered by the spec are sufficiently constraining that the behavior  
of indefinite variables, although unspecified, is effectively  
prescribed.

still, as at least one of these consequences is obvious in hindsight  
only, it is incumbent upon the implementations to document this  
behavior, if only so that i can be sure it will still be on the menu  
when i come back next week.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20091021/a2e86307/attachment.htm>