Is it legal for a conforming Common Lisp implementation to define
operators that are neither one of the twenty-five special operators,
nor functions, nor macros? I.e. symbols that can be used in the car
position of a list form who can not be macroexpanded and whose
arguments are evaluated in ways different than the normal
left-to-right, one-time-only order of function arguments.
-Peter
P.S. I would assume not but some things I saw in some old threads
about code walkers made me think I might be wrong.
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
I believe that it is legal for an implementation to provide its own
special operators, as an extension, provided they aren't exported from
the common lisp package and do not interfere with standard-conforming
code.
If a common lisp program uses these operators then it is
non-conforming.
Being non-conforming is not inherently good or bad--it is just
non-standard. Many times there are good reasons not to conform to a
standard. I don't like the term 'illegal', with its implication of
being wrong. Most implementations (of any language) extend the
standard while still providing a standard platform for code which is
standard-compliant.
Corman Lisp lets you define new special operators via DEFOP (a
non-standard macro). Basically I view a special operator as anything
which needs special handling by the compiler (can't be handled by
standard macro expansion or a function). If you are into goofing
around with compilers they are great. However there doesn't tend to be
much you need them for, and you have compiler macros in the standard
anyway.
Roger Corman
Corman Technologies
-----------------------------
Peter Seibel <·····@javamonkey.com> wrote in message news:<··············@javamonkey.com>...
> Is it legal for a conforming Common Lisp implementation to define
> operators that are neither one of the twenty-five special operators,
> nor functions, nor macros? I.e. symbols that can be used in the car
> position of a list form who can not be macroexpanded and whose
> arguments are evaluated in ways different than the normal
> left-to-right, one-time-only order of function arguments.
>
> -Peter
>
> P.S. I would assume not but some things I saw in some old threads
> about code walkers made me think I might be wrong.
From: Paul F. Dietz
Subject: Re: Implementation-defined "special operators" allowed?
Date:
Message-ID: <DMCdnXLPqdKtlDyiRVn-gw@dls.net>
Peter Seibel wrote:
> Is it legal for a conforming Common Lisp implementation to define
> operators that are neither one of the twenty-five special operators,
> nor functions, nor macros? I.e. symbols that can be used in the car
> position of a list form who can not be macroexpanded and whose
> arguments are evaluated in ways different than the normal
> left-to-right, one-time-only order of function arguments.
According to section 3.1.2.1.2, the car of a cons form must
be a special operator, or a function form (function name or
lambda form).
There's some question as to whether a conforming implementation
can have new special operators. The glossary entry for 'special
operator' would seem to indicate it cannot. However, the page
for MACRO-FUNCTION indicates it can. The intent of the latter is
that if some nonstandard symbol is also defined to be a special
operator (so SPECIAL-OPERATOR-P returns true on it), then MACRO-FUNCTION
on that symbol must also succeed, so user programs (read: code walkers)
can expand the special operator form into something a conforming program
can understand.
Paul
Peter Seibel <·····@javamonkey.com> writes:
> Is it legal for a conforming Common Lisp implementation to define
> operators that are neither one of the twenty-five special operators,
> nor functions, nor macros?
From CLHS 3.1.2.1.2 Conses as Forms:
If the car of [a] compound form is a symbol, that symbol is the
name of an operator, and the form is either a special form, a
macro form, or a function form, depending on the function binding
of the operator in the current lexical environment. If the
operator is neither a special operator nor a macro name, it is
assumed to be a function name
And 3.1.2.1.2.2 Macro Forms:
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.
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Peter Seibel <·····@javamonkey.com> writes:
> Is it legal for a conforming Common Lisp implementation to define
> operators that are neither one of the twenty-five special operators,
> nor functions, nor macros?
CLTL1/2 implicitly allowed for the the expansion of a standard
CL macro to contain non-standard special forms (see the
implementation note in 5.1.4)
I couldn't find a clear statement in the Hyperspec either way, though.
P.