From: Diodor Bitan
Subject: Need some help with Corman Lisp
Date: 
Message-ID: <f5f8f756.0306092244.3c3123b4@posting.google.com>
(progn 
    (defmacro plusmacro (x y) `(+ ,x ,y))
    (defun plus (a b) (plusmacro a b)))

;;; Warning: Function not defined: PLUSMACRO
PLUS

How can I make the plusmacro visible in the plus function? I
understand Corman Lisp compiles the progn form and then executes it,
so the macro isn't defined at compile time. I have tried using a
macrolet, but I've only got stuck with another problem:

(setq *test* -5)
-5

(macrolet
    ((testmacro (x) `(list *test* ,x)))
    (defun testfunc (*test* y)
        #'(lambda ()
            (testmacro y))))
;;; Warning: Symbol *TEST* assumed special
;;; Warning: Unused variable *TEST* in function TESTFUNC
TESTFUNC

(funcall (testfunc 10 15))
(-5 15)

Somehow the *test* gets bound to the global variable, not to the
parameter of the testfunc function.

From: Matthew Danish
Subject: Re: Need some help with Corman Lisp
Date: 
Message-ID: <20030610084956.GB17568@lain.mapcar.org>
On Mon, Jun 09, 2003 at 11:44:19PM -0700, Diodor Bitan wrote:
> (progn 
>   (defmacro plusmacro (x y) `(+ ,x ,y))
>   (defun plus (a b) (plusmacro a b)))
> 
> ;;; Warning: Function not defined: PLUSMACRO
> PLUS
> 
> How can I make the plusmacro visible in the plus function? I
> understand Corman Lisp compiles the progn form and then executes it,
> so the macro isn't defined at compile time. I have tried using a
> macrolet, but I've only got stuck with another problem:

Hmm.  I believe this is a bug in Corman Lisp.  Forms enclosed in a
top-level PROGN should be treated as if they were top-level too, IIRC.
Allegro and SBCL concur.

> (setq *test* -5)
> -5

Note that you are invoking undefined behavior, according to the
specification, by using SETQ on an undefined variable *TEST*.  This
could be important in explaining some of the strange results.

[reindented for readability]
> (macrolet ((testmacro (x) 
>             `(list *test* ,x)))
>   (defun testfunc (*test* y)
>     #'(lambda ()
>        (testmacro y))))
> ;;; Warning: Symbol *TEST* assumed special
> ;;; Warning: Unused variable *TEST* in function TESTFUNC
> TESTFUNC

As I see it, this should first expand into

(defun testfunc (*test* y)
  #'(lambda ()
      (list *test* y)))

And if *TEST* has not formerly been declared as special, then it is
considered a lexical variable, and this function should work as you
expect.

The two warning messages seem to indicate that something screwy is going
on in the macroexpansion step.  This might be due to the undefined
behavior you possibly invoked with SETQ, or it might be due to a bug.

> (funcall (testfunc 10 15))
> (-5 15)
> 
> Somehow the *test* gets bound to the global variable, not to the
> parameter of the testfunc function.

Actually, *TEST* is being treated as a special variable here.  Although
*TEST* is bound to 10 during the duration of the call to TESTFUNC, as
soon as TESTFUNC returns, the value of *TEST* reverts to -5.  Because
the variable *TEST* was assumed special within TESTFUNC, the function
returned by TESTFUNC itself treats *TEST* as a special variable and when
it is called, *TEST* has the value -5.

However, why *TEST* was assumed special is a mystery to me.  Corman 1.5,
which I tested this in, does not assume that, though it emits the other
warning.  In addition, it seems that Corman 1.5 assumes that a toplevel
SETQ creates a "global lexical variable" (though the next version may be
different).  From the code you posted, it seems that *TEST* should be
treated as a lexical variable.

Perhaps if Roger Corman is reading he can provide more information.

-- 
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
From: Diodor Bitan
Subject: Re: Need some help with Corman Lisp
Date: 
Message-ID: <f5f8f756.0306100710.7d24f572@posting.google.com>
This should make the second example simpler:

(macrolet
    ((testmacro (a) `(list x ,a)))
    (defun testfunc (x y)
        #'(lambda ()
            (testmacro y))))
;;; Warning: Symbol X assumed special
;;; Warning: Unused variable X in function TESTFUNC
TESTFUNC

(funcall (testfunc 10 15))
;;; An error occurred in function #< COMPILED-FUNCTION: #xFE47E8 >:
;;; Error: The variable X is unbound
From: Paul Foley
Subject: Re: Need some help with Corman Lisp
Date: 
Message-ID: <m2he6ygqcd.fsf@mycroft.actrix.gen.nz>
On 9 Jun 2003 23:44:19 -0700, Diodor Bitan wrote:

> (progn 
>     (defmacro plusmacro (x y) `(+ ,x ,y))
>     (defun plus (a b) (plusmacro a b)))

> ;;; Warning: Function not defined: PLUSMACRO
> PLUS

That would be a bug.

> (setq *test* -5)
> -5

> (macrolet
>     ((testmacro (x) `(list *test* ,x)))
>     (defun testfunc (*test* y)
>         #'(lambda ()
>             (testmacro y))))
> ;;; Warning: Symbol *TEST* assumed special
> ;;; Warning: Unused variable *TEST* in function TESTFUNC
> TESTFUNC

> (funcall (testfunc 10 15))
> (-5 15)

> Somehow the *test* gets bound to the global variable, not to the
> parameter of the testfunc function.

Don't call it *test* if it isn't intended to be special, and don't use
SETQ at top level; use SET or SETF of SYMBOL-VALUE, or LOCALLY declare
it special and then SETQ it, or something.  You can't close over a
special variable.

I don't know why you get the result you do, though; it doesn't look
like *test* was special before you defined testfunc, or you wouldn't
have got the warning, so it should be lexical...maybe Corman Lisp
assumes names with asterisks around them are intended to be special?
That would be weird :-)

-- 
When C++ is your hammer, everything looks like a thumb.
                                                     -- Steven M. Haflich
(setq reply-to
  (concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
From: Kent M Pitman
Subject: Re: Need some help with Corman Lisp
Date: 
Message-ID: <sfwadcqgp37.fsf@shell01.TheWorld.com>
Paul Foley <·······@actrix.gen.nz> writes:

> Don't call it *test* if it isn't intended to be special, and don't use
> SETQ at top level; use SET or SETF of SYMBOL-VALUE, or LOCALLY declare
> it special and then SETQ it, or something.  You can't close over a
> special variable.

And don't use SET.  Ever.

[It's not semantically ill-formed, just redundant.  And too good a name for
 such a rarely used function.  I'd like it to atrophy.]