Re: Woohoo! My macros are now (semi) hygienic

In article
<94725beb-cb19-4653-99e8-da7d4ce0d315@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Kaz Kylheku <kkylheku@xxxxxxxxx> wrote:

On Feb 25, 4:05 pm, Maciej Katafiasz <mathr...@xxxxxxxxx> wrote:
Den Mon, 25 Feb 2008 15:17:43 -0800 skrev Kaz Kylheku:

Suppose foo has a member x that you access in the DO block, and bar
doesn't have any member called x. So in that lexical scope, the name x
refers to foo.x. Suppose that someone now edits the type definition of
bar_record such that it acquires a member called x. Now when you
recompile the WITH statement above, the expression x suddenly refers to
bar.x! If bar.x is suitably typed, there will be no compiler error.
Unintentional shadowing of a local variable can also take place: bad
hygiene.

And that is different from (use-package :foo) how?

It's different in that USE-PACKAGE is required to detect conflicts,
which you have to explicitly deal with using SHADOW (resolve in favor
of local package) or UNINTERN (resolve in favor of library being
used).

The problem is that conflict-detection system for packages produces
false positives.

BTW, lexicons don't currently warn when existing bindings get shadowed
by new bindings, but there's no reason this feature couldn't be added if
people wanted it. It would be pretty easy to do.

What Ron is saying is that maintaining export lists by hand is some
kind of bug in packages that lexicons will fix for you.

One of several bugs that lexicons will fix (or, to put it more
diplomatically, one of several annoyances that lexicons will ameliorate).

That's the
only the case if you are using both systems in a certain way.

Of course. But that "certain way" is the most common way.

If you care about precisely what is accessible where, you have to
maintain lists, no matter what namespace system you are using.

No, you don't. Lexicons are really quite spiffy that way. You really
should take a look.

rg
.

Relevant Pages

  • Re: Woohoo! My macros are now (semi) hygienic
    ... bar_record such that it acquires a member called x. ... the expression x suddenly refers to ... What Ron is saying is that maintaining export lists by hand is some ... In the case of packages, you'd be maintaining import lists rather than ...
    (comp.lang.lisp)
  • Re: Woohoo! My macros are now (semi) hygienic
    ... with packages that Lexicons were designed to solve: ... namespaces into one scope is braindamaged. ... mean you don't have any control of the visibility of bindings. ... Suppose foo has a member x that you access in the DO block, ...
    (comp.lang.lisp)
  • Re: ANNOUNCE: Lexicons 2.0 (beta) released
    ... seamlessly integrated into Common Lisp (lexicons are now implemented ... using packages). ... Lexicons map symbols onto bindings at compile-time. ... what kind of "symbol sorting" are you using packages ...
    (comp.lang.lisp)
  • Re: Woohoo! My macros are now (semi) hygienic
    ... with packages that Lexicons were designed to solve: ... namespaces into one scope is braindamaged. ... involve that record type, everywhere in the program. ... Suppose foo has a member x that you access in the DO block, ...
    (comp.lang.lisp)
  • Re: Woohoo! My macros are now (semi) hygienic
    ... using packages. ... :-) Lexicons used as libraries have an explicit ... and so one binding will always shadow the other. ... also solved by lexicons, and I believe that some people will find ...
    (comp.lang.lisp)