From: danb
Subject: acl compile-file can't find a macro
Date: 
Message-ID: <5080be9f-52ae-430d-bedd-0bbdd5631755@y38g2000hsy.googlegroups.com>
I defined a macro (WHILE) before using it in the same file, but
ACL didn't seem to register its existence during compilation:

;;; Compiling file /usr/home/dan/progg/lib/cl/standard.lisp
Error: attempt to call `WHILE' which is an undefined function.
  [condition type: UNDEFINED-FUNCTION]

I just loaded the code into sbcl, and it runs fine.  The source file
(uploaded immediately after the error occured) is here:
http://www.prairienet.org/~dsb/mycode/cl/lib/standard.lisp

and the following *may* be all the relevant code, except acl didn't
say what line it errored on.  According to emacs (Ctrl-x < Ctrl-s),
the first occurance of WHILE is in the MACX form that defines it,
and the first call is in the definition of DEF.

(defmacro xport (&rest symbols)
  `(eval-when (:load-toplevel :execute) (export ',symbols)))

(defmacro macx (macro args &body body)
  `(progn
    (defmacro ,macro ,args ,@body)
    (xport ,macro)))

(macx while (test &body body) `(loop (unless ,test (return)) ,@body))

(macx def (func args &body defn)
  (let (preamble (body defn))
    (when (listp body)
      (when (stringp (car body)) (push (pop body) preamble))
      (while (and (listp (car body))
		  (eq (caar body) 'declare)) (push (pop body) preamble)))
        ...

--Dan

------------------------------------------------
Dan Bensen  http://www.prairienet.org/~dsb/

cl-match:  expressive pattern matching in Lisp
http://common-lisp.net/project/cl-match/

From: karsten
Subject: Re: acl compile-file can't find a macro
Date: 
Message-ID: <1e249c73-b751-4e2a-904f-52da822b660a@25g2000hsx.googlegroups.com>
Hello,
don't now why you don't see it, but the acl complains about the form
(defx gensyms (n) (loop repeat n collect (gensym)))
stating:
attempt to call `STANDARD::WHILE' which is an undefined function.
   [Condition of type UNDEFINED-FUNCTION]

You omitted the defpackage for standard, i assume it is like
(defpackage :standard
	    (:use :cl))

The interpreter is fine with the code, did you simply tried load?

Doing the following seems to make allegro happy too
(defmacro macx (macro args &body body)
  `(eval-when (:compile-toplevel :load-toplevel :execute)
    (defmacro ,macro ,args ,@body)
    (xport ,macro)))

But what are you trying to do, is that another arc in lisp?

Karsten
From: Marco Antoniotti
Subject: Re: acl compile-file can't find a macro
Date: 
Message-ID: <66782456-9b97-4fd1-9b22-e7805170227b@b64g2000hsa.googlegroups.com>
On May 7, 8:12 pm, danb <·········@gmail.com> wrote:
> I defined a macro (WHILE) before using it in the same file,

Why did you define such an utterly useless macro?

Cheers
--
Marco













 but
> ACL didn't seem to register its existence during compilation:
>
> ;;; Compiling file /usr/home/dan/progg/lib/cl/standard.lisp
> Error: attempt to call `WHILE' which is an undefined function.
>   [condition type: UNDEFINED-FUNCTION]
>
> I just loaded the code into sbcl, and it runs fine.  The source file
> (uploaded immediately after the error occured) is here:http://www.prairienet.org/~dsb/mycode/cl/lib/standard.lisp
>
> and the following *may* be all the relevant code, except acl didn't
> say what line it errored on.  According to emacs (Ctrl-x < Ctrl-s),
> the first occurance of WHILE is in the MACX form that defines it,
> and the first call is in the definition of DEF.
>
> (defmacro xport (&rest symbols)
>   `(eval-when (:load-toplevel :execute) (export ',symbols)))
>
> (defmacro macx (macro args &body body)
>   `(progn
>     (defmacro ,macro ,args ,@body)
>     (xport ,macro)))
>
> (macx while (test &body body) `(loop (unless ,test (return)) ,@body))
>
> (macx def (func args &body defn)
>   (let (preamble (body defn))
>     (when (listp body)
>       (when (stringp (car body)) (push (pop body) preamble))
>       (while (and (listp (car body))
>                   (eq (caar body) 'declare)) (push (pop body) preamble)))
>         ...
>
> --Dan
>
> ------------------------------------------------
> Dan Bensen  http://www.prairienet.org/~dsb/
>
> cl-match:  expressive pattern matching in Lisphttp://common-lisp.net/project/cl-match/
From: Willem Broekema
Subject: Re: acl compile-file can't find a macro
Date: 
Message-ID: <6a395126-bb72-4ef3-bc96-fa9184e5579f@x35g2000hsb.googlegroups.com>
On May 7, 8:12 pm, danb <·········@gmail.com> wrote:
> I defined a macro (WHILE) before using it in the same file, but
> ACL didn't seem to register its existence during compilation:

You are attempting to do things that are not guaranteed to work.

> (macx while (test &body body) `(loop (unless ,test (return)) ,@body))

Here are you are defining a macro "while". Okay. By the way, do you
know about:
 (loop while <test> do <body>)
A macro just to abbreviate that pattern has not much value, I'd agree
with Marco Antoniotti.

> (macx def (func args &body defn)
>   (let (preamble (body defn))
>     (when (listp body)
>       (when (stringp (car body)) (push (pop body) preamble))
>       (while (and (listp (car body))
>                   (eq (caar body) 'declare)) (push (pop body) preamble)))
>         ...

Here you are using macro while in the expansion function of another
macro later on in the same file. See <http://groups.google.com/group/
comp.lang.lisp/browse_frm/thread/170d01370010f113/> why this is not
guaranteed to work. Using eval-when, as Karsten suggested, is a
solution.

- Willem
From: Paul Donnelly
Subject: Re: acl compile-file can't find a macro
Date: 
Message-ID: <87k5i5k6sy.fsf@plap.localdomain>
Willem Broekema <········@gmail.com> writes:

> On May 7, 8:12 pm, danb <·········@gmail.com> wrote:
>> I defined a macro (WHILE) before using it in the same file, but
>> ACL didn't seem to register its existence during compilation:
>
> You are attempting to do things that are not guaranteed to work.
>
>> (macx while (test &body body) `(loop (unless ,test (return)) ,@body))
>
> Here are you are defining a macro "while". Okay. By the way, do you
> know about:
>  (loop while <test> do <body>)
> A macro just to abbreviate that pattern has not much value, I'd agree
> with Marco Antoniotti.

I'm fairly grateful for WHEN and UNLESS. Why not WHILE?
From: Kent M Pitman
Subject: Re: acl compile-file can't find a macro
Date: 
Message-ID: <ud4nxbk3x.fsf@nhplace.com>
Paul Donnelly <·············@sbcglobal.net> writes:

> I'm fairly grateful for WHEN and UNLESS. Why not WHILE?

(LOOP WHILE ...)

e.g.,

(let ((x 0)) (loop while (< x 3) do (print x) (incf x)))

0 
1 
2 
=> NIL

- - - - -

I can't find a reference to it offhand right this second, but
I vaguely recall that at some point in time in previous dialects, 
LOOP had the option of allowing keywords to all be macros themselves,
such that (WHILE ...) meant (LOOP WHILE ...), (FOR ...)
meant (LOOP FOR ...), but it was changed to avoid clutter of the
namespace and keep a lot of good names from being taken up.
This meant, implicitly, that there would not be opposition to
providing functionality in LOOP just because someone opposed the
chosen name...  So-called "LOOP keywords" are compared by
symbol name, not by symbol identity, so their meaning in LOOP doesn't
compete with their meaning outside.
From: Paul Donnelly
Subject: Re: acl compile-file can't find a macro
Date: 
Message-ID: <87bq3hjscb.fsf@plap.localdomain>
Kent M Pitman <······@nhplace.com> writes:

> Paul Donnelly <·············@sbcglobal.net> writes:
>
>> I'm fairly grateful for WHEN and UNLESS. Why not WHILE?
>
> (LOOP WHILE ...)
>
> e.g.,
>
> (let ((x 0)) (loop while (< x 3) do (print x) (incf x)))
>
> 0 
> 1 
> 2 
> => NIL

Well sure,

(if (not x) 'y) or (unless x 'y)

"While" seems just as reasonable to me. If I wrote a lot of that sort of
loop I'd probably have a macro for it. Avoiding name clobbering is good
in my book as well, but I can't see myself using "while" for anything
else.
From: Kent M Pitman
Subject: Re: acl compile-file can't find a macro
Date: 
Message-ID: <u3aotxli0.fsf@nhplace.com>
Paul Donnelly <·············@sbcglobal.net> writes:

> Kent M Pitman <······@nhplace.com> writes:
> 
> > Paul Donnelly <·············@sbcglobal.net> writes:
> >
> >> I'm fairly grateful for WHEN and UNLESS. Why not WHILE?
> >
> > (LOOP WHILE ...)
> >
> > e.g.,
> >
> > (let ((x 0)) (loop while (< x 3) do (print x) (incf x)))
> >
> > 0 
> > 1 
> > 2 
> > => NIL
> 
> Well sure,
> 
> (if (not x) 'y) or (unless x 'y)
> 
> "While" seems just as reasonable to me. If I wrote a lot of that sort of
> loop I'd probably have a macro for it. Avoiding name clobbering is good
> in my book as well, but I can't see myself using "while" for anything
> else.

Well, my point is that if you write:

 (defmacro while (&rest stuff) `(loop ,@stuff))

you are going to have to write:

 (let ((x 0)) (while (< x 3) do (print x) (incf x)))

when you might wish to write:

 (let ((x 0)) (while (< x 3) (print x) (incf x)))

And then there's the question of whether you want to be able to write,
which the above macro definition would allow:

 (let ((x 0))
  (while (< x 3)
   while (evenp x)
   do (print x) (incf x)))

Not to mention issues of whether RETURN should work in there.  That is,
whether you want

  (defmacro while (test &body forms)
    `(loop while (progn ,test) do (progn ,@forms)))

which would tolerate:

  (while t (return 3)) => 3

or whether you want 

 (defmacro while (test &body forms)
   (let ((tag (gensym)))
     `(loop named ,tag while (progn ,test) do (progn ,@forms))))

which requires you to write

 (block nil (while t (return 3)))

So, in fact, I think you probably CAN imagine wanting while to do
something else since I've offered 3 common-sense variations that I bet
you probably could see wanting to decide between.

Not all things reserved to the user are reserved for "big" reasons.

I suppose we could have just made arbitrary decisions and made you live
with it, but it didn't seem necessary.  LOOP already has the mechanism
to navigate all of that in an organized way.  We didn't need to reinvent
it separately.  It's kind of like the thing with the PROG special operator;
now that we have TAGBODY and BLOCK, it makes little sense to have it.
It's full of weird decisions.  It's mostly there for history's sake, from
a day when the language designers made random choices for you on matters
where the details turned out to matter more than had been expected.
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: acl compile-file can't find a macro
Date: 
Message-ID: <rem-2008may09-002@yahoo.com>
> From: danb <·········@gmail.com>
> I defined a macro (WHILE) before using it in the same file, but
> ACL didn't seem to register its existence during compilation:
> ;;; Compiling file /usr/home/dan/progg/lib/cl/standard.lisp
> Error: attempt to call `WHILE' which is an undefined function.
>   [condition type: UNDEFINED-FUNCTION]
> I just loaded the code into sbcl, and it runs fine.

Here's my educated guess as to the cause of your problem:
When you load something directly from source to your REP
environment, everything happens in that same environment,
interpretation and JIT compilation if your interpretor supports
that. So the only important thing is that macros are defined before
they are used, which you are doing (see details below). But when
you run the compiler to produce a compiled file, then in *another*
startup of Lisp you load that file, there are two different Lisp
environments, and some forms are evaluated in one but not the other.
To force something to be evaluated in *both* environments when
it normally wouldn't be, you need to wrap it with (eval-when ...).

> (defmacro xport (&rest symbols)
>   `(eval-when (:load-toplevel :execute) (export ',symbols)))

The compiler is hardcoded to know about DEFMACRO, whereby it is
evaluated in both the compiler and runtime evironment. No problem yet.

> (defmacro macx (macro args &body body)
>   `(progn
>     (defmacro ,macro ,args ,@body)
>     (xport ,macro)))

Same here.

> (macx while (test &body body) `(loop (unless ,test (return)) ,@body))

The compiler isn't hardwired to know about macx, so that form gets
compiled and written into the compiled file, to be executed later
at load time, but it is *not* evaluated in the compiler
environment, so the macros it implicitly defines (WHILE ad DEF) are
*not* available later in the compiler environment to be used to
expand code it's generating. So whenever the compiler sees a WHILE
or DEF form later it compiles linkage for calling a function by
that name, which doesn't work at runtime because there's no
function by either name. By chance, linkage to function WHILE bit
you first because that's the first such thing you tried running.

To fix this problem, you need to say this instead:
(eval-when (compile load) ;Check the HyperSpec to be sure these are correct
  (macx while (test &body body) `(loop (unless ,test (return)) ,@body))
  )
That will make sure the macro is available in the compiler
environment to expand forms that are being compiled, but also
available in the execution environment (after loading the compiled
file) in case you manually enter a (WHILE ...) form in the REP or
load an interpreted file with such a form in it.

> (macx def (func args &body defn) ...

Same problem here. Same fix.

So, anybody going to try my suggestion and see if it fixes the
problem and let me know whether it did?
From: danb
Subject: Re: acl compile-file can't find a macro
Date: 
Message-ID: <99a922a9-428a-4844-b9b4-ab20e20b7571@d45g2000hsc.googlegroups.com>
On May 9, 3:07 am, ···················@SpamGourmet.Com (Robert Maas,
http://tinyurl.com/uh3t) wrote:
> > (macx while (test &body body) `(loop (unless ,test (return)) ,@body))

> The compiler isn't hardwired to know about macx,
> so that form gets compiled and written into the
> compiled file, to be executed later at load time,
> but it is *not* evaluated in the compiler environment

> To fix this problem, you need to say this instead:
> (eval-when (compile load)
> ;Check the HyperSpec to be sure these are correct

Apparently, that's been replaced with
  (eval-when (:compile-toplevel :load-toplevel) ...

and it seems like you have to also include :execute
for when you load the source in directly.

> So, anybody going to try my suggestion and see if
> it fixes the problem and let me know whether it did?

Yes, that's what I did, and it works.  The only problem
now is that acl keeps generating messages that say
> Warning: compile-file found "EXPORT" at the top-level

> That will make sure the macro is available in the compiler
> environment to expand forms that are being compiled

Yea, I thought macro definitions were always eval'd,
because the HS says in section 3.2.3.1
Processing of Top Level Forms
http://www.lisp.org/HyperSpec/Body/sec_3-2-3-1.html

> If the form is a macro form, its macro expansion is
> computed and processed as a top level form in the same
> processing mode (compile-time-too or not-compile-time).

and then in section 3.2.3.1.1
Processing of Defining Macros
http://www.lisp.org/HyperSpec/Body/sec_3-2-3-1-1.html

> Defining macros (such as defmacro or defvar) appearing
> within a file being processed by compile-file normally
> have compile-time side effects which affect how subsequent
> forms in the same file are compiled.

but then it specifically rules out any guarantee:

> In particular, the information stored by the defining
> macros at compile time might or might not be available
> to the interpreter (either during or after compilation),
> or during subsequent calls to the compiler.

So I guess the sentence
> Defining macros...normally have compile-time side effects

is just a casual statement of common usage rather than
a specification.  The implied spec seems to be that the
side effects are unspecified/implementation-dependent.

--Dan

------------------------------------------------
Dan Bensen  http://www.prairienet.org/~dsb/

cl-match:  expressive pattern matching in Lisp
http://common-lisp.net/project/cl-match/
From: Robert Maas, http://tinyurl.com/uh3t
Subject: HotMail/EgyptianUniversities spammer harvesting from this newsgroup (was: acl compile-file can't find a macro)
Date: 
Message-ID: <rem-2008may29-004@yahoo.com>
> From: ···················@SpamGourmet.Com (Robert Maas, http://tinyurl.com/uh3t)
> Newsgroups: comp.lang.lisp

I posted several articles under this address, but one of them got
harvested by a Nigerian spammer. As a result, I've shut down this
address so that I won't get any more spam via this address. Any
e-mail sent to this address will be accepted by the server then
just discarded without any non-delivery notice. That's why I'm
posting this warning, just in case somebody saw any of my articles
just now and wants to reply to me privately If anybody wants to
send private e-mail to me regarding anything I've posted, you'll
have to look around to find some other variant address that I
haven't yet disabled, or go to my Web site and click on "Contact me".

Here's part of the Nigerian spam I got just today:
   Received: from mail.zu.edu.eg ([193.227.29.11]) by
   gourmet.spamgourmet.com (8.13.8/8.13.7) with ESMTP id m4TDS6bI013608
   for <···················@spamgourmet.com>; Thu, 29 May 2008 13:28:07
   GMT
This is the exact same IP number that sent me the Nigerian spam via
another of my SpamGourmet addresses just yesterday. Apparently
staff there just don't care to shut down the spammer.
RIPE WHOIS shows that IP number belongs to:
inetnum:         193.227.0.0 - 193.227.31.255
descr:           Egyptian Universities Network
person:          Gamal Mohamed Aly
address:         FRCU Computer Center
address:         Supereme Council of University
address:         Giza
address:         Egypt.
phone:           +2 02 5735405
phone:           +2 02 5738530
fax-no:          +2 02 5728174
e-mail:          ······@frcu.eun.eg
person:          Nashwa Abdel-Baki
address:         EUN Computer Center
address:         Supreme Council of Universities
address:         Cairo University Campus
address:         POBOX 268 Orman
address:         Giza
address:         Egypt
phone:           +2 02 5735405
phone:           +2 02 5738530
phone:           +2 02 7742344
phone:           +2 02 7742345
phone:           +2 02 7742346
fax-no:          +2 02 7742347
e-mail:          ······@MAILER.eun.eg

If there is any spam-hater located in Egypt and seeing this report,
please investigate the legal consequences of a university allowing
its local network to be repeatedly used for international
harassment and fraud. I'd like to see the person responsible for
security on that localnet fired, and charged with a crime of aiding
and abetting international crime, and the president of the
university held responsible for hiring a new localnet-security
expert who will prevent recurrance.

   Subject: URGENT. SIR/MA (usenet1: message 1 of 3)
   To: ···················@spamgourmet.com
   From: "STEVEN PERKMAN" <··············@hotmail.com>
That's exactly the same return address that was on the Nigerian
spam my other address got yesterday. More and more I'm convinced
that MicroSoft/HotMail is allowing this criminal activity to occur
using their facilities. If there is any spam-hater seeing this
report who has inside connections at hotmail, please investigate
who really owns that e-mail dropbox at HotMail, and why
MicroSoft/HotMail hasn't yet shut down that address and used the
power of its big interational corporation machinery to pressure
Egyption authorities to shut down use of their university computer
network for such international crime.

I know from past experience that MicroSoft/HotMail never does
anything to help victims of spam that comes directly from their own
IP numbers, so there's no way they'd be willing to investigate a
report of spam from some other ISP that uses a hotmail address as a
spammer's dropbox. IMO, Bill Gates should be arrested, charged with
felony conspiracy to commit interational fraud, racketeering, and
after conviction he should be kept in prison for the next twenty
years.

   I am Dr. STEVEN PERKMAN ,Managing Partner,with Robert Fore
   & Associates Law firm, Dubai Branch.Admitted, 1974.
   Education: LL.B 1973 Bristol University Practice
   Areas: Corporate; Commercial; Oil & Gas,International
   Trade; Banking, inheritance law, e.t.c
   On behalf of the Trustees and Executor of the Estate
   of Late George Brumley, I wish to notify you that late
   George Brumley made you one of the beneficiaries of
   his estate. He left the sum of Five Million One
   Hundred Thousand Dollars (USD$5,100.000.00 )to you.
(... the usual Nigerian pigeon-drop fake-money-laundering scam,
     the same text as yesterday's spam from the same IP number ...)

   http://www.cnn.com/2003/WORLD/africa/07/20/kenya.crash/index.html
(legitimate news story, same URL as in yesterday's spam)

The spam offers no way to reply to the spammer to arrange delivery
of fake bankcheque, except the hotmail address, so I'm thinking
that hotmail address really might be owned by the spammer. Too bad
the CAN-SPAM law protects MicroSoft from legal subpoenas regarding
their customers using MicroSoft services to engage in criminal
activity. Too bad MicroSoft has a policy of condoning use of their
servers to support criminal activity, taking full advantage of
their CAN-SPAM immunity. Too bad the citizens of this country are
too cowardly to take on MicroSoft directly by boycotting all their
products and services until MicroSoft starts being part of the
solution instead of part of the problem as they are currently.


-
Nobody in their right mind likes spammers, nor their automated assistants.
To open an account here, you must demonstrate you're not one of them.
Please spend a few seconds to try to read the text-picture in this box:

/----------------------------------------------------------------------------\
  | _._ )_|_  \  / _ |_| _ (~| _._   o    __|_   _   ._ _|_  _  _|_    _  |~
  |_\| |  |    \/ (_) _|(_| _|}_|   _||_|_\ |   (_|  | }_| |(_|_\| |  (_)~|~
  |  _  __|_  o._   (~|) _  _ _~)  /~\._  (~|) _  _ _  '|(~|(~|(~|~)
  |_(_)_\ |   || |  _)| (_|(_}_o   \_/|   _)| (_|(_}_   | /  /  / o
\----(Rendered by means of <http://www.schnoggo.com/figlet.html>)------------/
     (You don't need JavaScript or images to see that ASCII-text image!!
      You just need to view this in a fixed-pitch font such as Monaco.)

Then enter your best guess of the text (50-150 chars) into this TextArea:
   +------------------------------------------------------------+
   |                                                            |
   |                                                            |
   |                                                            |
   |                                                            |
   +------------------------------------------------------------+