I'm curious if there is a method of making sure that symbols will
evaluate "properly" across packages for use in a macro. For example, I
have a package that will generate ARM assembly code like so:
(addne r0 r0 r1 :lsl 4) => #x...
Of course, when I use these macros from outside the ARM package,
though, none of my symbols (registers) match those in the ARM package.
The only two ideas I can think of to ensure that they match would be
to:
1. Modify the instruction macro to always intern register symbols into
the current package (bad, IMO, but only for gut reasons) or
2. Create a reader character macro that will change which package I'm
in for the rest of the read:
{ (addne r0 r0 r1 :lsl 4) }
I'm willing to do (2) if that is general practice, but I was hoping
there might be something else I can do that may be a simpler solution
(as I have a lot of assembly code already in place -- I just recently
put the ARM macros in its own package.
Thanks,
Jeff M.
"Jeff M." <·······@gmail.com> writes:
> I'm curious if there is a method of making sure that symbols will
> evaluate "properly" across packages for use in a macro. For example, I
> have a package that will generate ARM assembly code like so:
>
> (addne r0 r0 r1 :lsl 4) => #x...
>
> Of course, when I use these macros from outside the ARM package,
> though, none of my symbols (registers) match those in the ARM package.
> The only two ideas I can think of to ensure that they match would be
> to:
>
> 1. Modify the instruction macro to always intern register symbols into
> the current package (bad, IMO, but only for gut reasons) or
The point is not that it's bad, it's that the symbols are interned by
the _reader_!
> 2. Create a reader character macro that will change which package I'm
> in for the rest of the read:
>
> { (addne r0 r0 r1 :lsl 4) }
Or you could just write: (in-package "ARM")
or just (use-package "ARM"), having taken care of exporting these symbols.
> I'm willing to do (2) if that is general practice, but I was hoping
> there might be something else I can do that may be a simpler solution
> (as I have a lot of assembly code already in place -- I just recently
> put the ARM macros in its own package.
You could write:
(use-package "ARM") (addne r0 r0 r1 :lsl 4)
or: (arm:addne arm:r0 arm:r0 arm:r1 :lsl 4)
or: (arm:addne :r0 :r0 :r1 :lsl 4)
or: (arm:addne "r0" "r0" "r1" :lsl 4)
or, now that you're ready to use STRING-EQUAL instead of EQL,
(addne mypackage::r0 the-other-package::r0 :r1 :lsl 4)
(and (string-equal 'r1 :r1) (string-equal 'p1::r1 'p2::r1))
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
From: Edi Weitz
Subject: Re: Macros and symbols across packages
Date:
Message-ID: <uwtpicq3o.fsf@agharta.de>
On 28 May 2005 23:00:32 -0700, "Jeff M." <·······@gmail.com> wrote:
> I'm curious if there is a method of making sure that symbols will
> evaluate "properly" across packages for use in a macro. For example,
> I have a package that will generate ARM assembly code like so:
>
> (addne r0 r0 r1 :lsl 4) => #x...
>
> Of course, when I use these macros from outside the ARM package,
> though, none of my symbols (registers) match those in the ARM
> package.
You could look at the symbol's /name/ only. This is basically what
LOOP does.
* (make-package :foo)
* (loop foo::for x foo::below 3 foo::collect x)
(0 1 2)
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Interesting. I didn't realize that symbol-name didn't also return the
package with the name when outside of the package (like print). I'll
give that a shot. Thanks.
However, I just tried your loop example with LW 4.4, and it works only
if foo::for isn't defined as a function. Still, good to know. Thanks.
Jeff M.
From: Edi Weitz
Subject: Re: Macros and symbols across packages
Date:
Message-ID: <ubr6um1im.fsf@agharta.de>
[Please quote some context when replying.]
On 29 May 2005 06:49:14 -0700, "Jeff M." <·······@gmail.com> wrote:
> However, I just tried your loop example with LW 4.4, and it works
> only if foo::for isn't defined as a function.
Really? I can't reproduce that with LWW 4.4.5. Do you have an
example?
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Hmm... I'm trying it again and can't seem to reproduce my original
error. Perhaps I typo'd before. False alarm.
Jeff M.
--
Pay no attention to the man behind the curtain.
From: Kent M Pitman
Subject: Re: Macros and symbols across packages
Date:
Message-ID: <uk6lh8qt9.fsf@nhplace.com>
"Jeff M." <·······@gmail.com> writes:
> Interesting. I didn't realize that symbol-name didn't also return the
> package with the name when outside of the package (like print). I'll
> give that a shot. Thanks.
Return is the wrong verb here. Show is the correct verb.
A symbol is, at least conceptually, a structure that always contains a
name and a backpointer to the symbol's home package. Whether the
printer decides to show the package depends on whether the symbol is
accessible in the current package or only reachable by reference
through a package. The package is always there, though, whether shown
or not.
The home package, incidentally, is only one of many packages the symbol
might be accessible through. It's used when the symbol is not accessible
locally if it is accessible through that home package. You can create
pathological cases where you unintern it from its home package and it
can't find a name to use for itself.
Kent M Pitman <······@nhplace.com> writes:
> "Jeff M." <·······@gmail.com> writes:
>
>> Interesting. I didn't realize that symbol-name didn't also return the
>> package with the name when outside of the package (like print). I'll
>> give that a shot. Thanks.
>
> Return is the wrong verb here. Show is the correct verb.
>
> A symbol is, at least conceptually, a structure that always contains a
> name and a backpointer to the symbol's home package. Whether the
> printer decides to show the package depends on whether the symbol is
> accessible in the current package or only reachable by reference
> through a package. The package is always there, though, whether shown
> or not.
>
> The home package, incidentally, is only one of many packages the symbol
> might be accessible through. It's used when the symbol is not accessible
> locally if it is accessible through that home package. You can create
> pathological cases where you unintern it from its home package and it
> can't find a name to use for itself.
Let it be clear: SYMBOL-NAME _returns_ only the name of the symbol.
PRINT may or may not _print_ (show) the name of the package,
according to the value of various special variables.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The rule for today:
Touch my tail, I shred your hand.
New rule tomorrow.
"Jeff M." <·······@gmail.com> writes:
> I'm curious if there is a method of making sure that symbols will
> evaluate "properly" across packages for use in a macro. For example, I
> have a package that will generate ARM assembly code like so:
>
> (addne r0 r0 r1 :lsl 4) => #x...
>
> Of course, when I use these macros from outside the ARM package,
> though, none of my symbols (registers) match those in the ARM package.
> The only two ideas I can think of to ensure that they match would be
> to:
>
> 1. Modify the instruction macro to always intern register symbols into
> the current package (bad, IMO, but only for gut reasons) or
As Pascal already pointed out, it is too late by the time your macro
executes, since the symbols have already been interned by the reader.
That is unless you decide to make the input be a string instead.
One solution, which BTW is used by the CL LOOP macro, is also mentioned
by Pascal: Test symbols via SYMBOL-NAME rather than EQ. That means the
macro that expands into the assembler doesn't care about the package,
but only about the name of the symbol used in this language.
> 2. Create a reader character macro that will change which package I'm
> in for the rest of the read:
No. I would not go this way.
> { (addne r0 r0 r1 :lsl 4) }
>
> I'm willing to do (2) if that is general practice, but I was hoping
> there might be something else I can do that may be a simpler solution
> (as I have a lot of assembly code already in place -- I just recently
> put the ARM macros in its own package.
>
What you left out was what I would consider the most reasonable way,
namely to export the symbols in the ARM package and then use that
package in places where you want the ARM macros to appear. I imagine
that you already did something like this to get your macro to be found.
I think that gives you the cleanest solution.
--
Thomas A. Russ, USC/Information Sciences Institute