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

Kaz Kylheku <kkylheku@xxxxxxxxx> wrote:
+---------------
| Maciej Katafiasz <mathr...@xxxxxxxxx> wrote:
| > 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).
+---------------

A third option [much less blunt than UNINTERN] is SHADOWING-IMPORT.

+---------------
| But USE-PACKAGE (and the :USE interface of DEFPACKAGE) are
| nevertheless blunt instruments.
+---------------

True, but often a handful of prior SHADOW or SHADOWING-IMPORT
operations can make USE-PACKAGE bearable.

And of course both :SHADOW and :SHADOWING-IMPORT clauses exist
in DEFPACKAGE, and their sequencing with the :USE clause is both
well-defined and useful:

http://alu.org/HyperSpec/Body/mac_defpackage.html
Macro DEFPACKAGE
...
The order in which the options appear in a DEFPACKAGE form is
irrelevant. The order in which they are executed is as follows:

1. :shadow and :shadowing-import-from.
2. :use.
3. :import-from and :intern.
4. :export.

SHADOWs are established first, since they might be necessary to
block spurious name conflicts when the :USE option is processed.
The :USE option is executed next so that :INTERN and :EXPORT
options can refer to normally inherited symbols. The :EXPORT
option is executed last so that it can refer to symbols created
by any of the other options; in particular, shadowing symbols
and imported symbols can be made external.

I have found that careful use of the :SHADOW and :SHADOWING-IMPORT
clauses can significantly improve the usability of the :USE clause.

+---------------
| If you care about precisely what is accessible where, you have to
| maintain lists, no matter what namespace system you are using.
|
| In the case of packages, you'd be maintaining import lists rather
| than export lists. I.e. lists of symbols which are arguments to
| :IMPORT-FROM or :SHADOWING-IMPORT-FROM in a DEFPACKAGE.
+---------------

Exactly. But depending upon the packages you want to inherit from, the
lists you will need of :SHADOW plus :SHADOWING-IMPORT-FROM symbols plus
packages :USE'd might (or might not) be a smaller maintainance burden
than the lists you's need for only :IMPORT-FROM or :SHADOWING-IMPORT-FROM
without any :USE.


-Rob

-----
Rob Warnock <rpw3@xxxxxxxx>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

.

Relevant Pages

  • Re: Why Im giving up on Lisp for now
    ... which means if I simply do a (USE-PACKAGE:LTK) ... Whereas if I shadow both PATH and VALUE, ... shadowing imports of PATH and VALUE before the USE-PACKAGE, ... the test harness code could simply ...
    (comp.lang.lisp)
  • Re: Eyes of the World - rapidan list
    ... Did you grow up in the shadow of a Baskin ... work as well for those lists, but it works ok, so I'm stuck on 31. ... But I like the Baskin Robbins idea! ...
    (rec.music.gdead)
  • Re: How to make a shadowed system disk
    ... >1) I can't seem to find out how to make a shadowed system disk. ... As with any shadow member, ... lists are not supported in SRM. ... and it mounts as a shadow set at some point during the boot process. ...
    (comp.os.vms)