[Openmcl-devel] New 0.14 binaries

[Gary Byers]

On Sat, 20 Dec 2003, Camille Troillard wrote:

>
> Although OpenMCL seems to run fine, I got a problem with ASDF files.
> Here is what I get while loading an ASDF system:
>
> ; loading system definition from
> ; /Users/camille/site-lisp/defsystems/cl-serve.asd into #<Package
> "ASDF265">
>  > Error in process listener(1): value CL-SERVE is not of the expected
> type STRING.
>
> If I modify:		(defsystem cl-serve ...
> to					(defsystem "cl-serve" ...
>
> Everything runs fine.  The problem is that everyone uses the latter
> syntax, so I guess OpenMCL has become more strictly bounded to the ANSI
> standard, but I can't tell as my Lisp knowledge is not broad enough.
>

Prior to 0.14-031220, you could do something like:

(defclass foo ()
  ((integer-slot :initarg :integer-slot :initform 0 :type integer)))

(make-instance 'foo :integer-slot 3.14159)

and the INTEGER-SLOT of that instance would have a non-integer value,
in violation of the type declaration.

If you try that in 0.14-031220, you'll get a TYPE-ERROR.

Either of these behaviors is permissible - the results are undefined,
as far as CLHS or the AMOP goes -, but I'd argue that that new
behavior is more useful more often.  If you don't care about the
slot's type, it could have been defaulted to or specified as T
(or perhaps NUMBER in this example); if you -do- care about the
slot's type, the CLOS implementation is now able to enforce type
constraints, and I think that it does that efficiently enough to
be practical.

This does mean that some code that had worked (by silently
ignoring slot type constraints) in previous versions of OpenMCL
now fails.  That codw was wrong: perhaps mildly and harmlessly
wrong, but wrong nonethesless.  It's certainly irritating and
puzzling to get TYPE-ERRORs when using code that used to appear
to work correctly, but there may be other cases where this
extra type chacking will find or prevent much more serious
bugs.

In ASDF's case, we seem to have:

(defclass component ()
  ((name :type string :accessor component-name :initarg :name :documentation
	 "Component name, restricted to portable pathname characters")
   ...))


(defclass module (component) ...)

(defclass system (module) ...)

and

(defmacro defsystem (name &body options)
   ...
   ( ...(make-instance ',class :name ',name)))

so (as you noted) if we do (DEFSYSTEM :some-symbol) we get a TYPE-ERROR
that (in at least one sense) we richly deserve.

The other argument would be that the :TYPE of the NAME slot is too
strict, and we seem to have evidence that symbols in fact make
perfectly reasonable COMPONENT-NAMEs (and have done so for some time.)
I'm not sure whether it'd be better to have the DEFSYSTEM macro
coerce its NAME argument to a string or whether it'd be better
for the slot to have a more lenient type constraint.

I'm a little surprised that other implementations haven't caught this;
that suggests that other programs in widespread use may have slot
type specs that are slightly out-of-synch with reality.  If that's
true, it'll certainly be a little irritating and frustrating to keep
encountering that.  In the long run, I think that the benefits of
doing this type checking will greatly outweigh the disadvantages,
and we may someday wonder how we ever got along without it.