I've put up an SBCL User Survey.

 http://random-state.net/sbcl-survey-2010.html

This survey is unofficial, but run by me in my capacity as an SBCL
developer. Please take a moment to fill it out, and forward the survey
URL to people who might not otherwise see it.

Summary of results will be published on the survey page.

Thank you,

 -- Nikodemus Siivola

Is there a way in SBCL to get the current function name?

(defun Foo ()
    (format t "executing ~A~%" <some way to retrieve function name">))

TheFlyingDutchman <zzbbaadd@aol.com> writes:

> Is there a way in SBCL to get the current function name?
>
> (defun Foo ()
>     (format t "executing ~A~%" <some way to retrieve function name">))

Yes.  The standard way:

(shadow 'defun)

(defmacro defun (name parameters &body body)
  (let ((docstring    (com.informatimago.common-lisp.source-form:extract-documentation body))
        (declarations (com.informatimago.common-lisp.source-form:extract-declarations  body))
        (body         (com.informatimago.common-lisp.source-form:extract-body          body)))
    `(cl:defun ,name ,parameters
       ,@(when docstring `(,docstring))
       ,@declarations
       (symbol-macrolet ((myself ',name))
         ,@body))))


(defun Foo ()
  (format t "executing ~A~%" myself))


CL-USER> (foo)
executing FOO
NIL


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

>
> Yes. =A0The standard way:
>
> (shadow 'defun)
>
> (defmacro defun (name parameters &body body)
> =A0 (let ((docstring =A0 =A0(com.informatimago.common-lisp.source-form:ex=
tract-documentation body))
> =A0 =A0 =A0 =A0 (declarations (com.informatimago.common-lisp.source-form:=
extract-declarations =A0body))
> =A0 =A0 =A0 =A0 (body =A0 =A0 =A0 =A0 (com.informatimago.common-lisp.sour=
ce-form:extract-body =A0 =A0 =A0 =A0 =A0body)))
> =A0 =A0 `(cl:defun ,name ,parameters
> =A0 =A0 =A0 =A0,@(when docstring `(,docstring))
> =A0 =A0 =A0 =A0,@declarations
> =A0 =A0 =A0 =A0(symbol-macrolet ((myself ',name))
> =A0 =A0 =A0 =A0 =A0,@body))))
>
> (defun Foo ()
> =A0 (format t "executing ~A~%" myself))
>
> CL-USER> (foo)
> executing FOO
> NIL

OK. Thanks. When you say "standard way", do you mean this is the type
of code a Lisp programmer would typically write in this situation, or
that this code at informatigo.com has become a standard?

Pascal J. Bourguignon <pjb@informatimago.com> wrote:
> TheFlyingDutchman <zzbbaadd@aol.com> writes:
> 
>> Is there a way in SBCL to get the current function name?
>>
>> (defun Foo ()
>>     (format t "executing ~A~%" <some way to retrieve function name">))
> 
> Yes.  The standard way:
> 
> (shadow 'defun)
> 
> (defmacro defun (name parameters &body body)
>  (let ((docstring    (com.informatimago.common-lisp.source-form:extract-documentation body))
>        (declarations (com.informatimago.common-lisp.source-form:extract-declarations  body))
>        (body         (com.informatimago.common-lisp.source-form:extract-body          body)))
>    `(cl:defun ,name ,parameters
>       ,@(when docstring `(,docstring))
>       ,@declarations
>       (symbol-macrolet ((myself ',name))
>         ,@body))))
> 
> 
> (defun Foo ()
>  (format t "executing ~A~%" myself))
> 
> 
> CL-USER> (foo)
> executing FOO
> NIL

That's a pretty clever use of anaphora. Would there be any problems in any
compilation environments (think eval-when) when using this macro?

-pete

TheFlyingDutchman <zzbbaadd@aol.com> writes:

>>
>> Yes. �The standard way:
>>
>> (shadow 'defun)
>>
>> (defmacro defun (name parameters &body body)
>> � (let ((docstring � �(com.informatimago.common-lisp.source-form:extract-documentation body))
>> � � � � (declarations (com.informatimago.common-lisp.source-form:extract-declarations �body))
>> � � � � (body � � � � (com.informatimago.common-lisp.source-form:extract-body � � � � �body)))
>> � � `(cl:defun ,name ,parameters
>> � � � �,@(when docstring `(,docstring))
>> � � � �,@declarations
>> � � � �(symbol-macrolet ((myself ',name))
>> � � � � �,@body))))
>>
>> (defun Foo ()
>> � (format t "executing ~A~%" myself))
>>
>> CL-USER> (foo)
>> executing FOO
>> NIL
>
> OK. Thanks. When you say "standard way", do you mean this is the type
> of code a Lisp programmer would typically write in this situation, or
> that this code at informatigo.com has become a standard?

I mean that unless I made a mistake, the code in
com.informatimago.common-lisp should be conforming code.

http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_c.htm#conforming_code

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Peter Keller <psilord@cs.wisc.edu> writes:

> Pascal J. Bourguignon <pjb@informatimago.com> wrote:
>> TheFlyingDutchman <zzbbaadd@aol.com> writes:
>> 
>>> Is there a way in SBCL to get the current function name?
>>>
>>> (defun Foo ()
>>>     (format t "executing ~A~%" <some way to retrieve function name">))
>> 
>> Yes.  The standard way:
>> 
>> (shadow 'defun)
>> 
>> (defmacro defun (name parameters &body body)
>>  (let ((docstring    (com.informatimago.common-lisp.source-form:extract-documentation body))
>>        (declarations (com.informatimago.common-lisp.source-form:extract-declarations  body))
>>        (body         (com.informatimago.common-lisp.source-form:extract-body          body)))
>>    `(cl:defun ,name ,parameters
>>       ,@(when docstring `(,docstring))
>>       ,@declarations
>>       (symbol-macrolet ((myself ',name))
>>         ,@body))))
>> 
>> 
>> (defun Foo ()
>>  (format t "executing ~A~%" myself))
>> 
>> 
>> CL-USER> (foo)
>> executing FOO
>> NIL
>
> That's a pretty clever use of anaphora. Would there be any problems in any
> compilation environments (think eval-when) when using this macro?

When not top-level, eval-when semantics mostly vanishes.  (I wonder what
you could do at load time to break it).  When top-level, I don't see how
eval-when could have any interference with a symbol-macrolet.

In any case, the typical use of such a feature would require further
non-hygiene, so eval-when is the least of our problems here.  That is,
if the programmer is careful enough to deal with the unhygienic things
he does to use that feature, he should also be able to deal with eval-when.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

On Oct 8, 2:01=A0pm, Peter Keller <psil...@cs.wisc.edu> wrote:
> Pascal J. Bourguignon <p...@informatimago.com> wrote:
>
>
>
>
>
> > TheFlyingDutchman <zzbba...@aol.com> writes:
>
> >> Is there a way in SBCL to get the current function name?
>
> >> (defun Foo ()
> >> =A0 =A0 (format t "executing ~A~%" <some way to retrieve function name=
">))
>
> > Yes. =A0The standard way:
>
> > (shadow 'defun)
>
> > (defmacro defun (name parameters &body body)
> > =A0(let ((docstring =A0 =A0(com.informatimago.common-lisp.source-form:e=
xtract-documentation body))
> > =A0 =A0 =A0 =A0(declarations (com.informatimago.common-lisp.source-form=
:extract-declarations =A0body))
> > =A0 =A0 =A0 =A0(body =A0 =A0 =A0 =A0 (com.informatimago.common-lisp.sou=
rce-form:extract-body =A0 =A0 =A0 =A0 =A0body)))
> > =A0 =A0`(cl:defun ,name ,parameters
> > =A0 =A0 =A0 ,@(when docstring `(,docstring))
> > =A0 =A0 =A0 ,@declarations
> > =A0 =A0 =A0 (symbol-macrolet ((myself ',name))
> > =A0 =A0 =A0 =A0 ,@body))))
>
> > (defun Foo ()
> > =A0(format t "executing ~A~%" myself))
>
> > CL-USER> (foo)
> > executing FOO
> > NIL
>
> That's a pretty clever use of anaphora. Would there be any problems in an=
y
> compilation environments (think eval-when) when using this macro?

[This conversation is really on the wrong thread :-) ]

No.  I only glanced at the code, but it looks conforming.  However,
you will get a compilation speed hit in Allegro CL, which does the
compilation of defun forms at top-level specially if defun has not
been redefined.  So I wouldn't necessarily recommend it.

A non-programming interface way to get the name of a function iff the
name is even available is to call inspect on the function object.

A programmable but non-portable way to get the name of a function
object in Allegro CL is to use the function excl::external-fn_symdef
on the function object.

Duane

Duane Rettig <duane@franz.com> writes:

> No.  I only glanced at the code, but it looks conforming.  However,
> you will get a compilation speed hit in Allegro CL, which does the
> compilation of defun forms at top-level specially if defun has not
> been redefined.  So I wouldn't necessarily recommend it.

You mean that Allegro CL implements defun as a special operator.

I would rather put it this way: you get a compilation speed improvement
from using a special operator instead of a macro as a toplevel form
(whatever the purpose).


It looks like we have two kinds of lisp programming style.   Some will
use mostly raw CL, and have as toplevel forms 99% of defun, defmacro and
defvar/defparameter.   Others will define a bunch of macros to define
various kind of application level stuff, and then you will have almost
0% of normal defuns.  In the later case, implementing cl:defun as a
special operator won't allow to shortcut the macro expansions.


Now, to consider compilation speed optimization, you really need:

1- to have a very big application to compile,
2- to be doing a lot of develoment on it.

I would not say that it's the case of the majority of the lispers
(unfortunately).  But it's definitely an interesting feature for paying
customers.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

On Oct 8, 6:01=A0pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> Duane Rettig <du...@franz.com> writes:
> > No. =A0I only glanced at the code, but it looks conforming. =A0However,
> > you will get a compilation speed hit in Allegro CL, which does the
> > compilation of defun forms at top-level specially if defun has not
> > been redefined. =A0So I wouldn't necessarily recommend it.
>
> You mean that Allegro CL implements defun as a special operator.

Not at all:

CL-USER(1): (special-operator-p 'let)
#<special operator LET @ #x2002773a>
CL-USER(2): (special-operator-p 'defun)
NIL
CL-USER(3): (describe 'let)
LET is a TENURED SYMBOL.
  It is unbound.
  It is EXTERNAL in the COMMON-LISP package and accessible in the
ACL-SOCKET, ACLMOP, COMMON-LISP-USER, COMPILER, CROSS-REFERENCE,
DEBUGGER, DEFSYSTEM, EXCL, EXCL.SCM, FOREIGN-FUNCTIONS, INSPECT, LEP,
LEP-IO, MULTIPROCESSING, NET.URI, NULL-PACKAGE-REPLY-SESSION,
PROFILER,
SYSTEM, and TOP-LEVEL packages.
  Its function binding is #<special operator LET @ #x2002773a>
    which function takes arguments ((&REST BINDINGS) &BODY BODY)
  Its property list has these indicator/value pairs:
EXCL::COMPLEX-SECTION-PARSER  2
COMPILER::.B-HANDLER.       COMPILER::BC-LET
COMPILER::.Q-HANDLER.       COMPILER::QC-LET
COMPILER::.Q-IMMED-HANDLER.  COMPILER::QC-LET-IMMED
COMPILER::.PT-HANDLER.      COMPILER::PT-LET
COMPILER::.PA.              COMPILER::PA-LET
COMPILER::.GLOB-SYMBOL-EXT.  138
COMPILER::.GLOB-SYMBOL.     138
EXCL::WALKER-TEMPLATE       EXCL::WALK-LET
CL-USER(4): (describe 'defun)
DEFUN is a TENURED SYMBOL.
  It is unbound.
  It is EXTERNAL in the COMMON-LISP package and accessible in the
ACL-SOCKET, ACLMOP, COMMON-LISP-USER, COMPILER, CROSS-REFERENCE,
DEBUGGER, DEFSYSTEM, EXCL, EXCL.SCM, FOREIGN-FUNCTIONS, INSPECT, LEP,
LEP-IO, MULTIPROCESSING, NET.URI, NULL-PACKAGE-REPLY-SESSION,
PROFILER,
SYSTEM, and TOP-LEVEL packages.
  Its function binding is #<macro DEFUN @ #x20029122>
    which macro takes arguments (NAME VARLIST &REST BODY)
  Its property list has these indicator/value pairs:
EXCL::SIMPLE-SECTION-TYPE   :OPERATOR
EXCL::SIMPLE-SECTION-PARSER  #<Function SECOND>
CL-USER(5):

I meant exactly what I had said.  The compiler treats an unmodified
defun specially, but we don't at all implement it as a special
operator.

> I would rather put it this way: you get a compilation speed improvement
> from using a special operator instead of a macro as a toplevel form
> (whatever the purpose).

No, it is only done for defun.

> It looks like we have two kinds of lisp programming style. =A0 Some will
> use mostly raw CL, and have as toplevel forms 99% of defun, defmacro and
> defvar/defparameter. =A0 Others will define a bunch of macros to define
> various kind of application level stuff, and then you will have almost
> 0% of normal defuns. =A0In the later case, implementing cl:defun as a
> special operator won't allow to shortcut the macro expansions.

Right.  This is actually a very common way to program in CL; it is
another way of describing what happens when you have a DSL (domain-
specific language).

> Now, to consider compilation speed optimization, you really need:
>
> 1- to have a very big application to compile,

Not really.  Compile a file with only a few defun forms in it and you
can see a difference.

> 2- to be doing a lot of develoment on it.

Yes - a common practice in Lisp.

> I would not say that it's the case of the majority of the lispers
> (unfortunately).

I disagree on your points, and so I also disagree with your
conclusion.

 =A0But it's definitely an interesting feature for paying
> customers.

You can try it yourself on our Express edition.  No need to be a
paying customer to see it.

Duane

* Duane Rettig [2010-10-09 07:15] writes:

> On Oct 8, 6:01�pm, p...@informatimago.com (Pascal J. Bourguignon)
>> You mean that Allegro CL implements defun as a special operator.
>
> Not at all:
....
> I meant exactly what I had said.  The compiler treats an unmodified
> defun specially, but we don't at all implement it as a special
> operator.

If it's not a function call and not macroexpanded then it must be a
special operator, no?

Helmut

On 09/10/2010 00:40, Duane Rettig wrote:
> On Oct 8, 2:01 pm, Peter Keller<psil...@cs.wisc.edu>  wrote:
>> Pascal J. Bourguignon<p...@informatimago.com>  wrote:
>>
>>
>>
>>
>>
>>> TheFlyingDutchman<zzbba...@aol.com>  writes:
>>
>>>> Is there a way in SBCL to get the current function name?
>>
>>>> (defun Foo ()
>>>>      (format t "executing ~A~%"<some way to retrieve function name">))
>>
>>> Yes.  The standard way:
>>
>>> (shadow 'defun)
>>
>>> (defmacro defun (name parameters&body body)
>>>   (let ((docstring    (com.informatimago.common-lisp.source-form:extract-documentation body))
>>>         (declarations (com.informatimago.common-lisp.source-form:extract-declarations  body))
>>>         (body         (com.informatimago.common-lisp.source-form:extract-body          body)))
>>>     `(cl:defun ,name ,parameters
>>>        ,@(when docstring `(,docstring))
>>>        ,@declarations
>>>        (symbol-macrolet ((myself ',name))
>>>          ,@body))))
>>
>>> (defun Foo ()
>>>   (format t "executing ~A~%" myself))
>>
>>> CL-USER>  (foo)
>>> executing FOO
>>> NIL
>>
>> That's a pretty clever use of anaphora. Would there be any problems in any
>> compilation environments (think eval-when) when using this macro?
>
> [This conversation is really on the wrong thread :-) ]
>
> No.  I only glanced at the code, but it looks conforming.  However,
> you will get a compilation speed hit in Allegro CL, which does the
> compilation of defun forms at top-level specially if defun has not
> been redefined.  So I wouldn't necessarily recommend it.

I don't understand this remark yet: Pascal's macro expands into a 
cl:defun, so if his new defun is used at the top level, the resulting 
cl:defun is also top-level. Why would there be a problem?


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/

Pascal Costanza <pc@p-cos.net> writes:

> On 09/10/2010 00:40, Duane Rettig wrote:
>> On Oct 8, 2:01 pm, Peter Keller<psil...@cs.wisc.edu>  wrote:
>>> Pascal J. Bourguignon<p...@informatimago.com>  wrote:
>>>
>>>
>>>
>>>
>>>
>>>> TheFlyingDutchman<zzbba...@aol.com>  writes:
>>>
>>>>> Is there a way in SBCL to get the current function name?
>>>
>>>>> (defun Foo ()
>>>>>      (format t "executing ~A~%"<some way to retrieve function name">))
>>>
>>>> Yes.  The standard way:
>>>
>>>> (shadow 'defun)
>>>
>>>> (defmacro defun (name parameters&body body)
>>>>   (let ((docstring    (com.informatimago.common-lisp.source-form:extract-documentation body))
>>>>         (declarations (com.informatimago.common-lisp.source-form:extract-declarations  body))
>>>>         (body         (com.informatimago.common-lisp.source-form:extract-body          body)))
>>>>     `(cl:defun ,name ,parameters
>>>>        ,@(when docstring `(,docstring))
>>>>        ,@declarations
>>>>        (symbol-macrolet ((myself ',name))
>>>>          ,@body))))
>>>
>>>> (defun Foo ()
>>>>   (format t "executing ~A~%" myself))
>>>
>>>> CL-USER>  (foo)
>>>> executing FOO
>>>> NIL
>>>
>>> That's a pretty clever use of anaphora. Would there be any problems in any
>>> compilation environments (think eval-when) when using this macro?
>>
>> [This conversation is really on the wrong thread :-) ]
>>
>> No.  I only glanced at the code, but it looks conforming.  However,
>> you will get a compilation speed hit in Allegro CL, which does the
>> compilation of defun forms at top-level specially if defun has not
>> been redefined.  So I wouldn't necessarily recommend it.
>
> I don't understand this remark yet: Pascal's macro expands into a
> cl:defun, so if his new defun is used at the top level, the resulting
> cl:defun is also top-level. Why would there be a problem?

It takes compilation time to expand my macro to the cl:defun form.

Moreover Duane says that AllegroCL processes cl:defun more efficiently
than a user provided equivalent macro that would have to be
macroexpanded.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

On Oct 9, 4:25=A0am, Pascal Costanza <p...@p-cos.net> wrote:
> On 09/10/2010 00:40, Duane Rettig wrote:
>
>
>
> > No. =A0I only glanced at the code, but it looks conforming. =A0However,
> > you will get a compilation speed hit in Allegro CL, which does the
> > compilation of defun forms at top-level specially if defun has not
> > been redefined. =A0So I wouldn't necessarily recommend it.
>
> I don't understand this remark yet: Pascal's macro expands into a
> cl:defun, so if his new defun is used at the top level, the resulting
> cl:defun is also top-level. Why would there be a problem?

Oops.

I didn't look at his definition carefully enough, and I especially
didn't see the shadow form - all I saw (or chose to see) was the
"(defmacro defun ..." and that triggered the memory of the defun-
redefinition issue.  In fact, according to the spec, a user can't
portably redefine defun anyway, so if I believed my own words, then I
would have been wrong about the code being conforming. I'm more
clearheaded today, now, so I do apologize to the other Pascal and to
those I misled with my mistake.

As for defun being a special-operator, I think it depends on whether
you take the spirit or the letter of the spec here.  Defun is indeed a
macro, and if you perform a defun at the top-level, macroexpand is
indeed performed on it.  It also does not react the way other special-
operators react, so that is why I said it is not a special-operator.

The way it _is_ treated specially, is in a compile-file situation;
instead of being macroexpanded, and the results of the macroexpansion
being processed in the fasl file as "cons this up with that ... now
evaluate this form", instead it performs truncated tasks that are
codified in the fasl file, and which don't require a macroexpansion to
be recorded and obeyed.  You can get a feel for the kinds of things
that are done in a defun form by macroexpandng your defun form and
examining the result.  This is reproduced in the fasl file, but at a
higher level, so it really is not only a compilation speed increase,
but also a space savings in the fasl file.

Finally, misspoke when I said that it was redefinition that stopped
the optimization; instead it is _encapsulation_ which thwarts that
optimization.  By encapsulation, I mean advise, defadvice, etc., and
since trace is no longer implemented on encapsulation, even tracing
defun doesn't thwart the optimization.  In my own defense, if my
memory serves correctly, we did check for redefinition long ago,
before redefinition of cl operators was disallowed, but the ansi
restriction allowed us to remove that part of it.

Sorry for the confusion.

Duane

On Oct 9, 5:02=A0am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> Pascal Costanza <p...@p-cos.net> writes:
>
> > I don't understand this remark yet: Pascal's macro expands into a
> > cl:defun, so if his new defun is used at the top level, the resulting
> > cl:defun is also top-level. Why would there be a problem?
>
> It takes compilation time to expand my macro to the cl:defun form.

Yes, and not only that, but it also the huge space used by defining a
macro and then evaluating that list-based form causes huge space
requirements in the fasl file.  We're able to keep our fasl sizes down
quite a bit as well.

> Moreover Duane says that AllegroCL processes cl:defun more efficiently
> than a user provided equivalent macro that would have to be
> macroexpanded.

Yes.  And as I apologized to you in my reply to Pascal C's message, I
also apologize here for misunderstanding your definition.

Duane

On 09/10/2010 19:07, Duane Rettig wrote:
> On Oct 9, 4:25 am, Pascal Costanza<p...@p-cos.net>  wrote:
>> On 09/10/2010 00:40, Duane Rettig wrote:
>>
>>
>>
>>> No.  I only glanced at the code, but it looks conforming.  However,
>>> you will get a compilation speed hit in Allegro CL, which does the
>>> compilation of defun forms at top-level specially if defun has not
>>> been redefined.  So I wouldn't necessarily recommend it.
>>
>> I don't understand this remark yet: Pascal's macro expands into a
>> cl:defun, so if his new defun is used at the top level, the resulting
>> cl:defun is also top-level. Why would there be a problem?
>
> Oops.
>
> I didn't look at his definition carefully enough, and I especially
> didn't see the shadow form - all I saw (or chose to see) was the
> "(defmacro defun ..." and that triggered the memory of the defun-
> redefinition issue.  In fact, according to the spec, a user can't
> portably redefine defun anyway, so if I believed my own words, then I
> would have been wrong about the code being conforming. I'm more
> clearheaded today, now, so I do apologize to the other Pascal and to
> those I misled with my mistake.
>
> As for defun being a special-operator, I think it depends on whether
> you take the spirit or the letter of the spec here.  Defun is indeed a
> macro, and if you perform a defun at the top-level, macroexpand is
> indeed performed on it.  It also does not react the way other special-
> operators react, so that is why I said it is not a special-operator.
>
> The way it _is_ treated specially, is in a compile-file situation;
> instead of being macroexpanded, and the results of the macroexpansion
> being processed in the fasl file as "cons this up with that ... now
> evaluate this form", instead it performs truncated tasks that are
> codified in the fasl file, and which don't require a macroexpansion to
> be recorded and obeyed.

It seems to me that this counts as 'defun being a special operator in 
Allegro, and this is actually also in line with the ANSI specification. 
See 3.1.2.1.2.2 Macro Forms: "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." It seems to me that that's 
the option you took in Allegro for 'defun...


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/

On Oct 9, 10:16=A0am, Pascal Costanza <p...@p-cos.net> wrote:
> On 09/10/2010 19:07, Duane Rettig wrote:
>
>
>
>
>
> > On Oct 9, 4:25 am, Pascal Costanza<p...@p-cos.net> =A0wrote:
> >> On 09/10/2010 00:40, Duane Rettig wrote:
>
> >>> No. =A0I only glanced at the code, but it looks conforming. =A0Howeve=
r,
> >>> you will get a compilation speed hit in Allegro CL, which does the
> >>> compilation of defun forms at top-level specially if defun has not
> >>> been redefined. =A0So I wouldn't necessarily recommend it.
>
> >> I don't understand this remark yet: Pascal's macro expands into a
> >> cl:defun, so if his new defun is used at the top level, the resulting
> >> cl:defun is also top-level. Why would there be a problem?
>
> > Oops.
>
> > I didn't look at his definition carefully enough, and I especially
> > didn't see the shadow form - all I saw (or chose to see) was the
> > "(defmacro defun ..." and that triggered the memory of the defun-
> > redefinition issue. =A0In fact, according to the spec, a user can't
> > portably redefine defun anyway, so if I believed my own words, then I
> > would have been wrong about the code being conforming. I'm more
> > clearheaded today, now, so I do apologize to the other Pascal and to
> > those I misled with my mistake.
>
> > As for defun being a special-operator, I think it depends on whether
> > you take the spirit or the letter of the spec here. =A0Defun is indeed =
a
> > macro, and if you perform a defun at the top-level, macroexpand is
> > indeed performed on it. =A0It also does not react the way other special=
-
> > operators react, so that is why I said it is not a special-operator.
>
> > The way it _is_ treated specially, is in a compile-file situation;
> > instead of being macroexpanded, and the results of the macroexpansion
> > being processed in the fasl file as "cons this up with that ... now
> > evaluate this form", instead it performs truncated tasks that are
> > codified in the fasl file, and which don't require a macroexpansion to
> > be recorded and obeyed.
>
> It seems to me that this counts as 'defun being a special operator in
> Allegro, and this is actually also in line with the ANSI specification.
> See 3.1.2.1.2.2 Macro Forms: "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." It seems to me that that's
> the option you took in Allegro for 'defun...

As I said earlier: I won't argue the finer points about what
constitutes special-operator-ness.  But also as I demonstrated,
special-operator-p returns nil for defun (because it is not a special
operator) and describe calls out the operator's definition as a macro
(as contrasted to other special operators like let, for which special-
operator-p and describe agree are special operators.

Duane

* Duane Rettig [2010-10-10 01:47] writes:

> As I said earlier: I won't argue the finer points about what
> constitutes special-operator-ness.  But also as I demonstrated,
> special-operator-p returns nil for defun (because it is not a special
> operator) and describe calls out the operator's definition as a macro
> (as contrasted to other special operators like let, for which special-
> operator-p and describe agree are special operators.

If your compiler doesn't macroexpand it (and doesn't call
*macroexpand-hook*) and special-operator-p returns nil then either your
compiler or your special-operator-p does not conform to the spec.

Helmut

Duane Rettig <duane@franz.com> writes:

> As I said earlier: I won't argue the finer points about what
> constitutes special-operator-ness.  But also as I demonstrated,
> special-operator-p returns nil for defun (because it is not a special
> operator) and describe calls out the operator's definition as a macro
> (as contrasted to other special operators like let, for which special-
> operator-p and describe agree are special operators.

Perhaps the following program:

    (with-open-file (src "/tmp/defun.lisp" :direction :output
                       :if-does-not-exist :create :if-exists :supersede)
     (print
       '(progn
         (eval-when (:compile-toplevel) (print (special-operator-p 'cl:defun)))
         (eval-when (:load-toplevel)    (print (special-operator-p 'cl:defun)))
         (defun f () (print (special-operator-p 'cl:defun)))) 
       src))
    (load (compile-file "/tmp/defun.lisp"))
    (f)


should print:

    T
    NIL
    NIL

in AllegroCL?



-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Helmut Eller <eller.helmut@gmail.com> writes:

> * Duane Rettig [2010-10-10 01:47] writes:
>
>> As I said earlier: I won't argue the finer points about what
>> constitutes special-operator-ness.  But also as I demonstrated,
>> special-operator-p returns nil for defun (because it is not a special
>> operator) and describe calls out the operator's definition as a macro
>> (as contrasted to other special operators like let, for which special-
>> operator-p and describe agree are special operators.
>
> If your compiler doesn't macroexpand it (and doesn't call
> *macroexpand-hook*) and special-operator-p returns nil then either your
> compiler or your special-operator-p does not conform to the spec.

Indeed.  What about compile-time *macroexpand-hook* ?

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

pjb@informatimago.com (Pascal J. Bourguignon) writes:

> Helmut Eller <eller.helmut@gmail.com> writes:
>
>> * Duane Rettig [2010-10-10 01:47] writes:
>>
>>> As I said earlier: I won't argue the finer points about what
>>> constitutes special-operator-ness.  But also as I demonstrated,
>>> special-operator-p returns nil for defun (because it is not a special
>>> operator) and describe calls out the operator's definition as a macro
>>> (as contrasted to other special operators like let, for which special-
>>> operator-p and describe agree are special operators.
>>
>> If your compiler doesn't macroexpand it (and doesn't call
>> *macroexpand-hook*) and special-operator-p returns nil then either your
>> compiler or your special-operator-p does not conform to the spec.
>
> Indeed.  What about compile-time *macroexpand-hook* ?

It doesn't get called when compiling cl:defun:


CL-USER(18): 
    (with-open-file (src "/tmp/defun.lisp" :direction :output
                       :if-does-not-exist :create :if-exists :supersede)
     (print
       '(progn
         (eval-when (:compile-toplevel) (print (special-operator-p 'cl:defun)))
         (eval-when (:load-toplevel)    (print (special-operator-p 'cl:defun)))
         (defun f () (print (special-operator-p 'cl:defun)))) 
       src))

CL-USER(19):     (load (compile-file "/tmp/defun.lisp"))
;;; Compiling file /tmp/defun.lisp

NIL 
;;; Writing fasl file /tmp/defun.fasl
;;; Fasl write complete
; Fast loading /tmp/defun.fasl

NIL 
T
CL-USER(20):     (f)

NIL 
NIL
CL-USER(21): (setf *macroexpand-hook* (lambda (&rest args) (print args) (apply (function funcall) args)))
#<Interpreted Function (unnamed) @ #x213ee6aa>
CL-USER(22):     (load (compile-file "/tmp/defun.lisp"))
;;; Compiling file /tmp/defun.lisp

(#<Macro Function (COMPILER-MACRO SETQ)>
 (SETQ EXCL:*SOURCE-PATHNAME* #P"/tmp/defun.lisp")
 #<Augmentable COMPILER environment 1 1>) 
(#<Macro Function (COMPILER-MACRO SETQ)>
 (SETQ EXCL:*SOURCE-PATHNAME* #P"/tmp/defun.lisp")
 #<Augmentable COMPILER environment 1 1 2 1>) 
NIL 
(#<Macro Function WHEN @ #x201101ca>
 (WHEN (AND OLD NEW) (STRING= (PATHNAME-NAME OLD) (PATHNAME-NAME NEW)))
 #<Augmentable INTERPRETER environment 1 1 1 1>) 
;;; Writing fasl file /tmp/defun.fasl
;;; Fasl write complete
; Fast loading /tmp/defun.fasl

NIL 
(#<Macro Function WHEN @ #x201101ca>
 (WHEN (AND OLD NEW) (STRING= (PATHNAME-NAME OLD) (PATHNAME-NAME NEW)))
 #<Augmentable INTERPRETER environment 1 1 1 1>) 
T
CL-USER(23): 



Which is a sure sign cl:defun is a special operator.
On the other hand, my other program (same thread!) prints NIL, NIL and
NIL 




Tested on:

"International Allegro CL Free Express Edition"
"8.2 [Linux (x86)] (Sep 11, 2010 7:36)"
("lisp_build 256")


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/