You can subscribe to this list here.
2009 
_{Jan}

_{Feb}
(3) 
_{Mar}
(1) 
_{Apr}

_{May}

_{Jun}
(5) 
_{Jul}
(3) 
_{Aug}
(5) 
_{Sep}
(2) 
_{Oct}
(6) 
_{Nov}
(2) 
_{Dec}
(1) 

2010 
_{Jan}
(16) 
_{Feb}
(1) 
_{Mar}
(10) 
_{Apr}
(4) 
_{May}
(3) 
_{Jun}

_{Jul}
(1) 
_{Aug}
(1) 
_{Sep}
(1) 
_{Oct}
(3) 
_{Nov}

_{Dec}
(1) 
2011 
_{Jan}
(3) 
_{Feb}
(6) 
_{Mar}

_{Apr}
(2) 
_{May}
(4) 
_{Jun}
(5) 
_{Jul}
(1) 
_{Aug}
(8) 
_{Sep}
(1) 
_{Oct}
(1) 
_{Nov}
(2) 
_{Dec}
(1) 
2012 
_{Jan}
(2) 
_{Feb}
(2) 
_{Mar}
(8) 
_{Apr}
(6) 
_{May}
(13) 
_{Jun}
(6) 
_{Jul}
(3) 
_{Aug}
(2) 
_{Sep}
(7) 
_{Oct}
(1) 
_{Nov}

_{Dec}

2013 
_{Jan}
(5) 
_{Feb}
(1) 
_{Mar}
(6) 
_{Apr}
(1) 
_{May}
(1) 
_{Jun}
(11) 
_{Jul}
(9) 
_{Aug}

_{Sep}
(4) 
_{Oct}

_{Nov}
(12) 
_{Dec}
(6) 
2014 
_{Jan}
(6) 
_{Feb}
(17) 
_{Mar}
(3) 
_{Apr}
(3) 
_{May}

_{Jun}
(4) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(1) 
2

3
(2) 
4

5

6

7

8

9
(1) 
10

11

12

13

14

15

16
(2) 
17

18

19

20

21

22

23

24

25

26

27

28

29

30

From: Christophe Rhodes <csr21@ca...>  20120616 21:13:14

Steve Stevenson <steve@...> writes: > This is a question rather than a bug ... I just want to have the > correct bit patterns. Can I turn off the trap and compute it? Put it > into hex? Really don't care how dirty it is. [ sbclhelp is probably a better place ] The dirtiest way is probably to use sbkernel:makesinglefloat (and makedoublefloat). The functions aren't maximally logical  the high word argument of each of the functions is signed, not unsigned  but they construct a float out of 32bit integer bit patterns in the obvious way. Cheers, Christophe 
From: Steve Stevenson <steve@cl...>  20120616 00:43:59

This is a question rather than a bug ... I just want to have the correct bit patterns. Can I turn off the trap and compute it? Put it into hex? Really don't care how dirty it is. Thanks.  D. E. (Steve) Stevenson (Almost emeritus) Associate Professor Director, Institute for Modeling and Simulation Applications. Clemson University steve at clemson dot edu Anyone who has ever looked into the glazed eyes of a soldier dying on the battlefield will think hard before starting a war. Otto von Bismarck, statesman (18151898) 
From: Christophe Rhodes <csr21@ca...>  20120609 08:32:50

Tomohiro Matsuyama <tomo@...> writes: > Then, we will get the following message. > > 10 must be a type of bit > > In a real world program, such a illegal function call might cause the program SEGV. > > The problem is that the subtypep states (function (bit) t) is subtype of (function (fixnum) t), though actually (function (bit) t) is NOT subtype of (function (fixnum) t), in a meaning of that a value of the subtype can be used as a value of supertype. > > That's what I wanted to explain. But: in CL, FUNCTION declarations aren't attached to function objects themselves, but to call sites (names). In each of the following cases, the declaration does not affect the object itself, but the call sites: see <http://www.lispworks.com/documentation/HyperSpec/Body/t_fn.htm#function>;. (let ((x (lambda (...) ...))) (declare (type (function (bit) t) x)) (funcall x 1)) (flet ((x (...) ...)) (declare (ftype (function (bit) t) x)) (x 1)) Christophe 
From: Tomohiro Matsuyama <tomo@cx...>  20120603 13:12:03

> > I have found some odd subtypep behavior on function type. > > > > CLUSER> (subtypep '(function (fixnum) fixnum) '(function (fixnum) integer)) > > T > > T > > CLUSER> (subtypep '(function (fixnum) fixnum) '(function (integer) integer)) > > T > > T > > CLUSER> (subtypep '(function (fixnum) fixnum) '(function (bit) integer)) > > NIL > > T > > > > As you may know, function parameters should be contravariant, meaning if we have a>b <: a'>b, then a' <: a must hold. So last two statement could be said wrong, or at least the second value should be false. > > I don't follow. In CL, and SBCL specifically covariance seems exactly > right to me. Can you unpack your reasoning a little? OK, let me explain my concern with a working example. Here, we have two functions: one takes an argument of type fixnum and another takes an argument of type bit. (declaim (type (function (fixnum) t) functionwithfixnumboundary)) (defparameter functionwithfixnumboundary (lambda (index) (declare (type fixnum index) (optimize (safety 0))) (format t "~D must be a type of fixnum~%" index))) (declaim (type (function (bit) t) functionwithbitboundary)) (defparameter functionwithbitboundary (lambda (index) (declare (type bit index) (optimize (safety 0))) (format t "~D must be a type of bit~%" index))) Both of functions are unsafe, meaning the type of the argument wouldn't be typechecked. Then, let's update the function reference carefully like: (defun variabletype (name) (cdr (assoc 'type (nthvalue 2 (sbcltl2:variableinformation name))))) (when (equal (multiplevaluelist (subtypep (variabletype 'functionwithbitboundary) (variabletype 'functionwithfixnumboundary))) '(t t)) (setq functionwithfixnumboundary functionwithbitboundary)) The above assignment will be evaluated because (function (bit) t) <: (function (fixnum) t) is valid in SBCL. Now, call the function like (note that this function call should be valid): (funcall functionwithfixnumboundary 10) Then, we will get the following message. 10 must be a type of bit In a real world program, such a illegal function call might cause the program SEGV. The problem is that the subtypep states (function (bit) t) is subtype of (function (fixnum) t), though actually (function (bit) t) is NOT subtype of (function (fixnum) t), in a meaning of that a value of the subtype can be used as a value of supertype. That's what I wanted to explain.  Tomohiro Matsuyama <tomo@...> 
From: Nikodemus Siivola <nikodemus@ra...>  20120603 10:18:08

On 1 June 2012 04:20, Tomohiro Matsuyama <tomo@...> wrote: > I have found some odd subtypep behavior on function type. > > CLUSER> (subtypep '(function (fixnum) fixnum) '(function (fixnum) integer)) > T > T > CLUSER> (subtypep '(function (fixnum) fixnum) '(function (integer) integer)) > T > T > CLUSER> (subtypep '(function (fixnum) fixnum) '(function (bit) integer)) > NIL > T > > As you may know, function parameters should be contravariant, meaning if we have a>b <: a'>b, then a' <: a must hold. So last two statement could be said wrong, or at least the second value should be false. I don't follow. In CL, and SBCL specifically covariance seems exactly right to me. Can you unpack your reasoning a little? If I replace a (function (integer) integer) with (function (fixnum) fixnum) any callsite that relied on the previous definition is still safe: they may now get an error due to narrowing of the type, but any typebased reasoning the system did is still valid. Ie. "if F returns, the thing it returns must be an integer". Of course CLHS SUBTYPEP doesn't specify SUBTYPEP properly  so perhaps we should return NIL, NIL in case of both covariance and contravariance, and implement FSUBTYPEP (or possibly FTYPESCOVARIANTP and FTYPESCONTRAVARIANTP.) Cheers,  Nikodemus 
From: Tomohiro Matsuyama <tomo@cx...>  20120601 01:56:54

Hi, I have found some odd subtypep behavior on function type. CLUSER> (subtypep '(function (fixnum) fixnum) '(function (fixnum) integer)) T T CLUSER> (subtypep '(function (fixnum) fixnum) '(function (integer) integer)) T T CLUSER> (subtypep '(function (fixnum) fixnum) '(function (bit) integer)) NIL T As you may know, function parameters should be contravariant, meaning if we have a>b <: a'>b, then a' <: a must hold. So last two statement could be said wrong, or at least the second value should be false. CLHS says subtypep could return (values nil nil) if it sees `function' on the typespec.  Tomohiro Matsuyama <tomo@...> 