Re: [Sbcl-devel] Values types and subtypep

[Christophe R. <cs...@ca...>]

On Thu, Nov 28, 2002 at 02:36:12PM +0300, Alexey Dejneka wrote:
> Christophe Rhodes <cs...@ca...> writes:
> 
> > other
> > reading material is the thread on cmucl-imp in June of 2000
> 
> Where can I find it? I've downloaded cmucl-imp.[12] from
> www3.cons.org, but between them there is a gap in that time.

I've put a gzipped copy of the relevant thread up at
<http://www-jcsu.jesus.cam.ac.uk/~csr21/values.bug187.cmucl-imp.gz>.

> > Here, however, we would not like any bad things to happen, because the
> > receiver is capable of receiving something of type (values index index).
> 
> Semantics of VALUES type specifier is defined in terms of M-V-CALL,
> not M-V-BIND.
> 
> (multiple-value-call
>     (lambda (x y)
>       (declare (index x y))
>       (list x y))
>   (foo -1))
> 
> is invalid. So I don't see your second operation.

You could well be right; I remain fairly confused.

> > So, the conclusion is that two distinct type operations are needed; or
> > possibly two distinct values types are required -- in any case, some
> > distinction needs to be made between these two cases.
> 
> I think the problem grows from the non-uniform treating of simple and
> complex forms of VALUES:
> (ANSI-CL:VALUES t1 ... tn) \approx (VALUES &OPTIONAL t1 ... tn &REST T).
> 
> Uniform VALUES probably allows to optimize code better, and Python
> uses something similar to it. Maybe we should just rename VALUES to
> PYTHON-VALUES, use it inside the SBCL and define CL:VALUES in terms of
> it?

This may end up being the right solution; I think that that might have
been the upshot of the CMUCL discussion...

Cheers,

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)