Prev: [CfP] 2nd International Workshop on Context-oriented Programming
Next: google "go" vs common lisp
From: Zach Beane on 22 Feb 2010 19:48
Ron Garret <rNOSPAMon(a)flownet.com> writes:

> Feedback welcome. Note that this version runs only on Clozure Common
> Lisp because it relies on some compiler hacks.

Steps 2 and 3 in your "now have to go through the following" can be
combined with a single SHADOWING-IMPORT or :shadowing-import-from clause
in a re-evaluated DEFPACKAGE.

Zach
From: Zach Beane on 22 Feb 2010 20:36
Ron Garret <rNOSPAMon(a)flownet.com> writes:

> Feedback welcome.

How does this interact with cl-ppcre's compiler macro for SCAN?

Zach
From: Ron Garret on 22 Feb 2010 22:05
In article <87y6ikraw1.fsf(a)hangup.portland.xach.com>,
Zach Beane <xach(a)xach.com> wrote:

> Ron Garret <rNOSPAMon(a)flownet.com> writes:
>
> > Feedback welcome.
>
> How does this interact with cl-ppcre's compiler macro for SCAN?
>
> Zach

It should have no effect. The way lexicons work (now -- it was very
different before) is that all symbols in the lexicons package get
"lexified", which means that they get both a regular macro and a symbol
macro defined for them whose expansion is simply to replace the symbol
with the symbol of the same name in the lexicon's package. So
(lexicons::scan ...) is a macro that expands to (cl-ppcre:scan ...). So
any compiler macro defined on cl-ppcre:scan should Just Work.

(Actually, what lexicons::scan expands to depends on the the current
lexicon and its parent and libraries, which is what makes lexicons
actually useful. But in any case, because lexicons are now such a thin
layer on top of packages everything should work seamlessly, more or
less.)

rg
From: Ron Garret on 22 Feb 2010 22:11
In article <873a0ssro5.fsf(a)hangup.portland.xach.com>,
Zach Beane <xach(a)xach.com> wrote:

> Ron Garret <rNOSPAMon(a)flownet.com> writes:
>
> > Feedback welcome. Note that this version runs only on Clozure Common
> > Lisp because it relies on some compiler hacks.
>
> Steps 2 and 3 in your "now have to go through the following" can be
> combined with a single SHADOWING-IMPORT or :shadowing-import-from clause
> in a re-evaluated DEFPACKAGE.
>
> Zach

That's true, but this is just a simple example to illustrate how
lexicons work. The more usual case (at least for me) is to load a whole
bunch of code having forgotten to load the corresponding library. At
that point it's not just one symbol that's potentially conflicting, it's
a whole bunch of them. And shadowing-importing them all may or may not
be the right thing to do. And in any case you then still have to reload
all the client code.

The other advantage of lexicons is that you don't have to manually
maintain export lists. In addition to a parent, lexicons also have a
list of "library" lexicons. The library lexicons are not searched
recursively. So when you build a library now all you have to do it put
all the public code in one lexicons, all the private code in a second
lexicon which is in the first lexicon's library, and voila! All the
public stuff is visible and all the private stuff is hidden. Lexicons
let you stay DRY :-)

rg
From: Zach Beane on 23 Feb 2010 06:11
Ron Garret <rNOSPAMon(a)flownet.com> writes:

> In article <87y6ikraw1.fsf(a)hangup.portland.xach.com>,
> Zach Beane <xach(a)xach.com> wrote:
>
>> Ron Garret <rNOSPAMon(a)flownet.com> writes:
>>
>> > Feedback welcome.
>>
>> How does this interact with cl-ppcre's compiler macro for SCAN?
>>
>> Zach
>
> It should have no effect. The way lexicons work (now -- it was very
> different before) is that all symbols in the lexicons package get
> "lexified", which means that they get both a regular macro and a symbol
> macro defined for them whose expansion is simply to replace the symbol
> with the symbol of the same name in the lexicon's package. So
> (lexicons::scan ...) is a macro that expands to (cl-ppcre:scan ...). So
> any compiler macro defined on cl-ppcre:scan should Just Work.

When does the compiler macro get expanded in the example on your blog?
Is that "Resolving binding..." a message indicating recompilation of
FOO?

Zach
 |  Next  |  Last
Pages: 1 2 3
Prev: [CfP] 2nd International Workshop on Context-oriented Programming
Next: google "go" vs common lisp