Hello,
In CLISP the following code returns NIL:
(let ((*read-default-float-format* nil))
*read-default-float-format*)
In SBCL it signals an error
The value NIL
is not of type
(MEMBER LONG-FLOAT DOUBLE-FLOAT SINGLE-FLOAT SHORT-FLOAT).
[Condition of type TYPE-ERROR]
It seems that SBCL does not allow NIL as a value for
*read-default-float-format*
The spec says that the parameter *read-default-float-format* has a
value type:
"one of the atomic type specifiers short-float,
single-float, double-float, or long-float, or else some other type
specifier defined by the implementation to be acceptable."
therefore my understanding is that SBCL is conformant.
So, is there a way to bypass this behaviour and force SBCL to also
accept NIL as a value type? I ask this because I stumbled to the
following problem with CLSQL package:
I tried to create an object, of the type
(def-view-class point ()
((point-id :type integer :reader point-id
:db-kind :key :db-constraints :primary-key)
(basename :type (string 255) :accessor
basename :initarg :basename)
(latitude :type float :accessor
latitude :initarg :latitude)
(longitude :type float :accessor
longitude :initarg :longitude))
(:default-initargs :basename nil :latitude nil :longitude nil))
I want to also accept nil as a value for latitude and longitude, which
are of type float. But, CLSQL uses the following code
(defmethod database-output-sql-as-type ((type (eql 'float))
val database db-type)
(declare (ignore database db-type))
(let ((*read-default-float-format* (type-of val)))
(format nil "~F" val)))
and signals the error above.
What do you think? Whose fault is this and how should I bypass this
problem using SBCL?
Thanks,
Giorgos Pontikakis
··················@gmail.com wrote:
> In CLISP the following code returns NIL:
>
> (let ((*read-default-float-format* nil))
> *read-default-float-format*)
>
> In SBCL it signals an error
>
> The value NIL
> is not of type
> (MEMBER LONG-FLOAT DOUBLE-FLOAT SINGLE-FLOAT SHORT-FLOAT).
> [Condition of type TYPE-ERROR]
The ANS is unambiguous about the legal values for
*read-default-float-format*. You want it to be NIL, but you haven't
explained why you want this value, and in particular, how you expect NIL
to be understood when the reader or printer need to examine it.
Under the ANS, the value of *read-default-float-format* only portably
affects the operation of the reader and printer when reading or printing
floats. If an implementation doesn't understand NIL, then behavior is
undefined if you try to set the value to NIL. Undefined behavior ranges
from Doing What I Mean to halting your computer and transforming it into
a moulten puddle of metal, silicon, and plastic on the floor.
CLSQL, as you note, apparently expects a latitude or longitude to be
some sort of floating point number. NIL is not a floating point number
despite what the perpetrators of broken languages like Java might think.
> It seems that SBCL does not allow NIL as a value for
> *read-default-float-format*
> ...
> therefore my understanding is that SBCL is conformant.
Yes.
> So, is there a way to bypass this behavior and force SBCL to also
> accept NIL as a value type?
Yes, it's open source, so you can rewrite SBCL any way you like. But
that's probably not a useful answer.
> I ask this because I stumbled to the
> following problem with CLSQL package:
>
> I tried to create an object, of the type
>
> (def-view-class point ()
> ((point-id :type integer :reader point-id
> :db-kind :key :db-constraints :primary-key)
> (basename :type (string 255) :accessor basename :initarg :basename)
> (latitude :type float :accessor latitude :initarg :latitude)
> (longitude :type float :accessor longitude :initarg :longitude))
> (:default-initargs :basename nil :latitude nil :longitude nil))
>
> I want to also accept nil as a value for latitude and longitude, which
> are of type float. But, CLSQL uses the following code
>
> (defmethod database-output-sql-as-type ((type (eql 'float))
> val database db-type)
> (declare (ignore database db-type))
> (let ((*read-default-float-format* (type-of val)))
> (format nil "~F" val)))
Perhaps this function is not prepared to accept non-floating-point
values for val.
> What do you think? Whose fault is this and how should I bypass this
> problem using SBCL?
Whether or not it works in any particular implementation, it is not a
conforming form in ANSI CL. If it is acceptable to pass a non-float
value as the val parameter to this function, the bug would be in CLSQL,
assuming CLSQL claims to be an ANSI CL application. The appropriate
type specifier in Common Lisp would be (or null float).
It might be easier (and more productive) to rewrite CLSQL than SBCL.
But still more productive would be consider why you want NIL to be an
acceptable latitude or longitude.