CLTH 2 contains following paragraph:
Implementation note: Implementors are encouraged to implement the
macros defined in this book, as far as is possible, in such a way that
the expansion will not contain any implementation-dependent special
forms, nor contain as forms data objects that are not considered to be
forms in Common Lisp. The purpose of this restriction is to ensure that
the expansion can be processed by a program-analyzing program in an
implementation-independent manner. There is no problem with a macro
expansion containing calls to implementation-dependent functions. This
restriction is not a requirement of Common Lisp; it is recognized that
certain complex macros may be able to expand into significantly more
efficient code in certain implementations by using
implementation-dependent special forms in the macro expansion.
So what implementions have not any implementation-dependent special
forms?
PS For example clisp expands
(handler-bind ((error #'trap-error-handler)) (print "hello")))
into
(LET
((#:G739 #'(LAMBDA NIL (PROGN #'TRAP-ERROR-HANDLER)))
(#:G740 #'(LAMBDA NIL (PROGN (PRINT "hello")))))
(LOCALLY (DECLARE (COMPILE))
(SYSTEM::%HANDLER-BIND
((ERROR #'(LAMBDA (CONDITION) (FUNCALL (FUNCALL #:G739)
CONDITION))))
(FUNCALL #:G740))))
But system::%handler-bind nor function nor macro nor special
form.........
"Alexander" <········@gmail.com> writes:
> So what implementions have not any implementation-dependent special
> forms?
I don't know any such implementations.
(let ((nonstandard-special-operators '()))
(do-all-symbols (symbol)
(when (and (special-operator-p symbol)
(not (eq (nth-value 1 (find-symbol (symbol-name symbol)
"COMMON-LISP"))
:external)))
(push symbol nonstandard-special-operators)))
nonstandard-special-operators)
> But system::%handler-bind nor function nor macro nor special
> form.........
That sounds like a bug.
The compiler of CLISP 2.34 apparently supports system::%handler-bind,
but the interpreter doesn't. Regardless, I think it should be marked
as a special operator.
> I don't know any such implementations.
So code walkers have to be ajusted for every existing implemention?
> (let ((nonstandard-special-operators '())) ....
I see. Thanks.
>> But system::%handler-bind nor function nor macro nor special
>> form.........
>That sounds like a bug.
clisp 2.33.2
Alexander wrote:
>>I don't know any such implementations.
>
> So code walkers have to be ajusted for every existing implemention?
The section in the HyperSpec that describes that non-standard special
operators should have equivalent macro definitions is supposed to help
implementors of code walkers not to have to think about them. In a code
walker, you can then still macroexpand them away.
If an implementation provides non-standard special operators but no
corresponding macro definitions that expand to the standard set of
special operators, then that's a violation of the spec.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> Alexander wrote:
>>>I don't know any such implementations.
>> So code walkers have to be ajusted for every existing implemention?
>
> The section in the HyperSpec that describes that non-standard special
> operators should have equivalent macro definitions is supposed to help
> implementors of code walkers not to have to think about them. In a
> code walker, you can then still macroexpand them away.
>
> If an implementation provides non-standard special operators but no
> corresponding macro definitions that expand to the standard set of
> special operators, then that's a violation of the spec.
Hmmm, I wish that were true but I don't see it. Here's what I think is
the relevant bit from the spec:
"An implementation is free to implement a Common Lisp special
operator as a macro. An implementation is free to implement any
macro operator as a special operator, but only if an equivalent
definition of the macro is also provided."
The first sentence just says that standard special operators can be
macros which isn't relevant. And the second sentence I've always
understood to mean that it's fine for an implementation to actually
compile a standard macro specially (i.e. other than by expanding it
and compiling the expansion) but it still has to provide a macro
definition for the reasons you say. But the implementation still has
the right to define its own non-standard special operators and I don't
see how this (or anything else I've found) obligates it to treat those
special operators as if they were really macros and thus under control
of this clause. Is there somewhere else that you're thinking of or are
you just reading this sentence differently than I am?
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>>Alexander wrote:
>>
>>>>I don't know any such implementations.
>>>
>>>So code walkers have to be ajusted for every existing implemention?
>>
>>The section in the HyperSpec that describes that non-standard special
>>operators should have equivalent macro definitions is supposed to help
>>implementors of code walkers not to have to think about them. In a
>>code walker, you can then still macroexpand them away.
>>
>>If an implementation provides non-standard special operators but no
>>corresponding macro definitions that expand to the standard set of
>>special operators, then that's a violation of the spec.
>
> Hmmm, I wish that were true but I don't see it. Here's what I think is
> the relevant bit from the spec:
>
> "An implementation is free to implement a Common Lisp special
> operator as a macro. An implementation is free to implement any
> macro operator as a special operator, but only if an equivalent
> definition of the macro is also provided."
>
> The first sentence just says that standard special operators can be
> macros which isn't relevant. And the second sentence I've always
> understood to mean that it's fine for an implementation to actually
> compile a standard macro specially (i.e. other than by expanding it
> and compiling the expansion) but it still has to provide a macro
> definition for the reasons you say. But the implementation still has
> the right to define its own non-standard special operators and I don't
> see how this (or anything else I've found) obligates it to treat those
> special operators as if they were really macros and thus under control
> of this clause. Is there somewhere else that you're thinking of or are
> you just reading this sentence differently than I am?
Yes, I am reading it differently. The first part talks about _Common
Lisp_ special operators which may be implemented as macros. The second
part talks about _any_ macro operator which may be implemented as a
special operator but which must have an equivalent macro definition.
Please also take into consideration that 3.1.2.1.2.1 Special Forms says
the following:
"The set of special operators is fixed in Common Lisp; no way is
provided for the user to define a special operator. The next figure
lists all of the Common Lisp symbols that have definitions as special
operators."
Note that it doesn't say "symbols in the common-lisp package".
Am I too nit-picking? ;)
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> Peter Seibel wrote:
>> Pascal Costanza <··@p-cos.net> writes:
>>>If an implementation provides non-standard special operators but no
>>>corresponding macro definitions that expand to the standard set of
>>>special operators, then that's a violation of the spec.
>> Hmmm, I wish that were true but I don't see it. Here's what I think
>> is
>> the relevant bit from the spec:
>> "An implementation is free to implement a Common Lisp special
>> operator as a macro. An implementation is free to implement any
>> macro operator as a special operator, but only if an equivalent
>> definition of the macro is also provided."
>> The first sentence just says that standard special operators can be
>> macros which isn't relevant. And the second sentence I've always
>> understood to mean that it's fine for an implementation to actually
>> compile a standard macro specially (i.e. other than by expanding it
>> and compiling the expansion) but it still has to provide a macro
>> definition for the reasons you say. But the implementation still has
>> the right to define its own non-standard special operators and I don't
>> see how this (or anything else I've found) obligates it to treat those
>> special operators as if they were really macros and thus under control
>> of this clause. Is there somewhere else that you're thinking of or are
>> you just reading this sentence differently than I am?
>
> Yes, I am reading it differently. The first part talks about _Common
> Lisp_ special operators which may be implemented as macros. The second
> part talks about _any_ macro operator which may be implemented as a
> special operator but which must have an equivalent macro definition.
Right. But that doesn't--to me--say anything about
implementation-defined special operators which *aren't* macro
operators. I.e. I claim an implementation can define its own special
operators simply as special operators; this is just saying if you
provide a special operator for something that *has* to be a macro
(because it's defined as a macro in the spec) then you *also* have to
provide a macro definition.
> Please also take into consideration that 3.1.2.1.2.1 Special Forms
> says the following:
>
> "The set of special operators is fixed in Common Lisp; no way is
> provided for the user to define a special operator. The next figure
> lists all of the Common Lisp symbols that have definitions as
> special operators."
I think the key word in that passage is "user". There's no way for a
user to define a special operator but the implementation can.
> Note that it doesn't say "symbols in the common-lisp package".
>
> Am I too nit-picking? ;)
I think so, yes. I think Common Lisp symbols is synonymous with
"symbols in the COMMON-LISP package"; otherwise they'd just have said
"symbols".
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>>Peter Seibel wrote:
>>
>>>Pascal Costanza <··@p-cos.net> writes:
>
>>>>If an implementation provides non-standard special operators but no
>>>>corresponding macro definitions that expand to the standard set of
>>>>special operators, then that's a violation of the spec.
>>>
>>>Hmmm, I wish that were true but I don't see it. Here's what I think
>>>is
>>>the relevant bit from the spec:
>>> "An implementation is free to implement a Common Lisp special
>>> operator as a macro. An implementation is free to implement any
>>> macro operator as a special operator, but only if an equivalent
>>> definition of the macro is also provided."
>>>The first sentence just says that standard special operators can be
>>>macros which isn't relevant. And the second sentence I've always
>>>understood to mean that it's fine for an implementation to actually
>>>compile a standard macro specially (i.e. other than by expanding it
>>>and compiling the expansion) but it still has to provide a macro
>>>definition for the reasons you say. But the implementation still has
>>>the right to define its own non-standard special operators and I don't
>>>see how this (or anything else I've found) obligates it to treat those
>>>special operators as if they were really macros and thus under control
>>>of this clause. Is there somewhere else that you're thinking of or are
>>>you just reading this sentence differently than I am?
>>
>>Yes, I am reading it differently. The first part talks about _Common
>>Lisp_ special operators which may be implemented as macros. The second
>>part talks about _any_ macro operator which may be implemented as a
>>special operator but which must have an equivalent macro definition.
>
> Right. But that doesn't--to me--say anything about
> implementation-defined special operators which *aren't* macro
> operators. I.e. I claim an implementation can define its own special
> operators simply as special operators; this is just saying if you
> provide a special operator for something that *has* to be a macro
> (because it's defined as a macro in the spec) then you *also* have to
> provide a macro definition.
>
>>Please also take into consideration that 3.1.2.1.2.1 Special Forms
>>says the following:
>>
>>"The set of special operators is fixed in Common Lisp; no way is
>>provided for the user to define a special operator. The next figure
>>lists all of the Common Lisp symbols that have definitions as
>>special operators."
>
> I think the key word in that passage is "user". There's no way for a
> user to define a special operator but the implementation can.
>
>
>>Note that it doesn't say "symbols in the common-lisp package".
>>
>>Am I too nit-picking? ;)
>
> I think so, yes. I think Common Lisp symbols is synonymous with
> "symbols in the COMMON-LISP package"; otherwise they'd just have said
> "symbols".
OK, you're right. I have double-checked with CLtL2, and there is an
enlightening paragraph in 5.1.4 Macros:
"Implementors are encouraged to implement the macros defined in this
book, as far as is possible, in such a way that the expansion will not
contain any implementation-dependent special forms, nor contain as forms
data objects that are not considered to be forms in Common Lisp. The
purpose of this restriction is to ensure that the expansion can be
processed by a program-analyzing program in an
implementation-independent manner. There is no problem with a macro
expansion containing calls to implementation-dependent functions. This
restriction is not a requirement of Common Lisp; it is recognized that
certain complex macros may be able to expand into significantly more
efficient code in certain implementations by using
implementation-dependent special forms in the macro expansion."
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
In article <···············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Please also take into consideration that 3.1.2.1.2.1 Special Forms says
> the following:
>
> "The set of special operators is fixed in Common Lisp; no way is
> provided for the user to define a special operator. The next figure
> lists all of the Common Lisp symbols that have definitions as special
> operators."
No way is provided for the *user* to define special operators. But the
implementor is not a user.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***