I must be very stupid. In SBCL 1.01 (and 0.9.12)
(let ((/ 1))
/ )
complains about 1 being not type List. And,
(let ((/ '(1 2 3)))
/)
apparently works for 0.9.12.
For cmucl, both are ok. What's wrong?
howard yeh wrote:
> I must be very stupid. In SBCL 1.01 (and 0.9.12)
>
> (let ((/ 1))
> / )
>
> complains about 1 being not type List. And,
>
> (let ((/ '(1 2 3)))
> /)
>
> apparently works for 0.9.12.
CL:/ is a special variable that contains the list of values returned by
the last expression evaluated at the REPL. I suppose its type (list) is
proclaimed and checked in SBCL, but not in CMUCL.
Note that the problem has nothing to do with the printed representation
of the symbol. For example:
CL-USER> (defpackage #:a (:export #:/))
#<PACKAGE "A">
CL-USER> (let ((a:/ 23)) a:/)
23
Paul Khuong
·······@gmail.com wrote:
> howard yeh wrote:
>> I must be very stupid. In SBCL 1.01 (and 0.9.12)
>>
>> (let ((/ 1))
>> / )
>>
>> complains about 1 being not type List. And,
>>
>> (let ((/ '(1 2 3)))
>> /)
>>
>> apparently works for 0.9.12.
>
> CL:/ is a special variable that contains the list of values returned
> by the last expression evaluated at the REPL. I suppose its type
> (list) is proclaimed and checked in SBCL, but not in CMUCL.
Yes, but the OP has given </> local lexical scope via <let>.
Seems like that should definitely override the global meaning of </>
in that local environment.
Carl Taylor
Carl Taylor wrote:
> ·······@gmail.com wrote:
> > howard yeh wrote:
> >> I must be very stupid. In SBCL 1.01 (and 0.9.12)
> >>
> >> (let ((/ 1))
> >> / )
> >>
> >> complains about 1 being not type List. And,
> >>
> >> (let ((/ '(1 2 3)))
> >> /)
> >>
> >> apparently works for 0.9.12.
> >
> > CL:/ is a special variable that contains the list of values returned
> > by the last expression evaluated at the REPL. I suppose its type
> > (list) is proclaimed and checked in SBCL, but not in CMUCL.
>
> Yes, but the OP has given </> local lexical scope via <let>.
> Seems like that should definitely override the global meaning of </>
> in that local environment.
It's a *special* variable (and is proclaimed as such via
defvar/defparameter), not a global. "Specialness" can't be undone;
there's a "special" declaration, but no "lexical" one.
Paul Khuong
Carl Taylor wrote:
> ·······@gmail.com wrote:
>
>> howard yeh wrote:
>>
>>> I must be very stupid. In SBCL 1.01 (and 0.9.12)
>>>
>>> (let ((/ 1))
>>> / )
>>>
>>> complains about 1 being not type List. And,
>>>
>>> (let ((/ '(1 2 3)))
>>> /)
>>>
>>> apparently works for 0.9.12.
>>
>>
>> CL:/ is a special variable that contains the list of values returned
>> by the last expression evaluated at the REPL. I suppose its type
>> (list) is proclaimed and checked in SBCL, but not in CMUCL.
>
>
> Yes, but the OP has given </> local lexical scope via <let>.
Yikes, no. The coolest thing about special variables is that LET
/rebinds/ the special variable, not that it despecializes them. LET
establishes this binding only for the duration of the LET, then restores
any binding which held beforehand. This works recursively, and being a
special the binding is seen by any code anywhere running during that
binding -- ie, by any dynamic access.
Here is all the code needed to run some code outside the Cells machinery:
(defun call-without-c-dependency (fn)
(let (*call-stack*)
(funcall fn)))
How cool is that? Note that as soon as that LET exits, Cells is back in
control.
kzo
--
The Dalai Lama gets the same crap all the time.
-- Kenny Tilton on c.l.l when accused of immodesty
Ken Tilton <·········@gmail.com> writes:
> Carl Taylor wrote:
>> ·······@gmail.com wrote:
>>
>>> howard yeh wrote:
>>>
>>>> I must be very stupid. In SBCL 1.01 (and 0.9.12)
>>>>
>>>> (let ((/ 1))
>>>> / )
>>>>
>>>> complains about 1 being not type List. And,
>>>>
>>>> (let ((/ '(1 2 3)))
>>>> /)
>>>>
>>>> apparently works for 0.9.12.
>>>
>>>
>>> CL:/ is a special variable that contains the list of values returned
>>> by the last expression evaluated at the REPL. I suppose its type
>>> (list) is proclaimed and checked in SBCL, but not in CMUCL.
>>
>>
>> Yes, but the OP has given </> local lexical scope via <let>.
>
> Yikes, no. The coolest thing about special variables is that LET
I fail to find in CLHS where it's specified that /, //, ///, etc are
to be dynamic variables. Note that they're not constants and they're
not named */* *//* and *///*.
AFAIK, the REPL could be implemented as:
(loop (print (eval `(let ((/ REPL:last-results)
(// REPL:last-last-results)
(/// REPL:last-last-last-results)
;; ...
)
,(read)))))
Perhaps we could want to redeclare the type in the local scopes:
(let ((/ 1)) (declare (type / t)) /)
but SBCL says:
debugger invoked on a SB-INT:COMPILED-PROGRAM-ERROR: Execution of a form compiled with errors.
Form:
(LET ((/ 1)) (DECLARE (TYPE T /)) /)
Compile-time error:
Lock on package COMMON-LISP violated when declaring the type of /.
See also:
The SBCL Manual, Node "Package Locks"
The ANSI Standard, Section 11.1.2.1.2
11.1.2.1.2 says:
11. Declaring or proclaiming its type or ftype (via declare,
declaim, or proclaim). (Some exceptions are noted below.)
and 11.1.2.1.2.1 says:
If an external symbol of the COMMON-LISP package is not globally
defined as a standardized dynamic variable or constant variable,
it is allowed to lexically bind it and to declare the type of that
binding, and it is allowed to locally establish it as a symbol
macro (e.g., with symbol-macrolet).
Unless explicitly specified otherwise, if an external symbol of
the COMMON-LISP package is globally defined as a standardized
dynamic variable, it is permitted to bind or assign that dynamic
variable provided that the ``Value Type'' constraints on the
dynamic variable are maintained, and that the new value of the
variable is consistent with the stated purpose of the variable.
These paragraphs clearly speak of _dynamic_ _variables_, while the
CLHS page of / speak of _variables_.
This should mean that an implementation is free to use dynamic or
lexical variables for /, //, ///, etc.
In both case, I think SBCL is entitled by CLHS to behave like it does.
The OP will have to either shadow / or to bind to it only lists.
(Of course, an alternative is to use another implementation and write
an implementation specific program).
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Indentation! -- I will show you how to indent when I indent your skull!"
Pascal Bourguignon <···@informatimago.com> wrote:
> I fail to find in CLHS where it's specified that /, //, ///, etc are
> to be dynamic variables.
You didn't look in 1.4.4.14.
--
Juho Snellman
Juho Snellman <······@iki.fi> writes:
> Pascal Bourguignon <···@informatimago.com> wrote:
>> I fail to find in CLHS where it's specified that /, //, ///, etc are
>> to be dynamic variables.
>
> You didn't look in 1.4.4.14.
Ok, so they're specified to be dynamic variables.
--
__Pascal Bourguignon__ http://www.informatimago.com/
HANDLE WITH EXTREME CARE: This product contains minute electrically
charged particles moving at velocities in excess of five hundred
million miles per hour.
"The variables /, //, and /// are maintained by the Lisp
read-eval-print loop to save the values of results that were printed at
the end of the loop."
This applies only in REPL, so should working when compiling the
expression?
I should try it out myself, but I don't have a lisp implementation
handy.
·······@gmail.com wrote:
> howard yeh wrote:
> > I must be very stupid. In SBCL 1.01 (and 0.9.12)
> >
> > (let ((/ 1))
> > / )
> >
> > complains about 1 being not type List. And,
> >
> > (let ((/ '(1 2 3)))
> > /)
> >
> > apparently works for 0.9.12.
>
> CL:/ is a special variable that contains the list of values returned by
> the last expression evaluated at the REPL. I suppose its type (list) is
> proclaimed and checked in SBCL, but not in CMUCL.
>
> Note that the problem has nothing to do with the printed representation
> of the symbol. For example:
>
> CL-USER> (defpackage #:a (:export #:/))
> #<PACKAGE "A">
> CL-USER> (let ((a:/ 23)) a:/)
> 23
>
> Paul Khuong
howard yeh wrote:
> I must be very stupid. In SBCL 1.01 (and 0.9.12)
>
> (let ((/ 1))
> / )
>
> complains about 1 being not type List. And,
>
> (let ((/ '(1 2 3)))
> /)
>
> apparently works for 0.9.12.
>
> For cmucl, both are ok. What's wrong?
Nah, you're not stupid. Maybe a bug in SBCL??
Both of your examples work fine in LispWorks.
Carl Taylor
CL-USER 1 >
(let ((/ 1))
/ )
1
CL-USER 2 >
(let ((/ '(1 2 3)))
/)
(1 2 3)
howard yeh wrote:
> I must be very stupid. In SBCL 1.01 (and 0.9.12)
>
> (let ((/ 1))
> / )
>
> complains about 1 being not type List. And,
>
> (let ((/ '(1 2 3)))
> /)
>
> apparently works for 0.9.12.
>
> For cmucl, both are ok. What's wrong?
Nah, you're not stupid. Maybe a bug in SBCL??
Both of your examples work fine in LispWorks.
Carl Taylor
CL-USER 1 >
(let ((/ 1))
/ )
1
CL-USER 2 >
(let ((/ '(1 2 3)))
/)
(1 2 3)