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

In article
<31ee5725-d999-4306-9ce0-114e2e3faa6c@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
"Leslie P. Polzer" <leslie.polzer@xxxxxxx> wrote:

I'm very interested in this stuff. I don't have time for checking it
out
right now, though. What will we get when you officially release it?

I'm shooting for Monday. It's mostly a matter of writing a primer, and
deleting some old code that doesn't work any more. And testing.

Could you make up a quick comparison of what package problems it will
solve?

There are two main problems (or maybe I should call them annoyances)
with packages that Lexicons were designed to solve:

1. The need to manually build and maintain exported symbol lists

2. The fact that the reader causes side-effects which, if packages have
not been properly set up, can be difficult to undo. For example, if you
load some code that relies on a package before that package has been
used then you end up with interned symbols in the using package that now
must all be uninterned before the package can be used.

I'm actually particularly proud of the solution to problem #2 because
lexicons can "defer" lexical bindings, e.g.:

? (in-lexicon "LIBRARY")
#<lexicon LIBRARY>
? (ldefun library-function () 'library)
LIBRARY-FUNCTION
? (in-lexicon "MYLEX")
#<lexicon MYLEX>
? (ldefun my-fn () (library-function))
; Warning: Defering lexical binding of LIBRARY-FUNCTION
; While executing: *REF, in process Listener(117).
MY-FN

; Oops, forgot to import the library

? (use-lexicon "LIBRARY")
(#<lexicon LIBRARY> #<lexicon JACK> #<lexicon BOB>)
? (my-fn)
Resolving lexical binding of LIBRARY-FUNCTION
LIBRARY
?


So for this common class of error, not only do you not have to clean up
your package, but most of the time you don't even have to recompile your
code.

Contrast that with the package situation:

? (in-package "LIBRARY")
#<Package "LIBRARY">
? (defun pkg-library-function () 'pkg-library-function)
PKG-LIBRARY-FUNCTION
? (export 'pkg-library-function)
T
? (in-package :cl-user)
#<Package "COMMON-LISP-USER">
? (defun pkg-my-fn () (pkg-library-function))
;Compiler warnings :
; Undefined function PKG-LIBRARY-FUNCTION, in PKG-MY-FN.
PKG-MY-FN
? (use-package "LIBRARY")
Error: Using #<Package "LIBRARY"> in #<Package "COMMON-LISP-USER">
would cause name conflicts with symbols already present in that package:
PKG-LIBRARY-FUNCTION LIBRARY:PKG-LIBRARY-FUNCTION
LIBRARY-FUNCTION LIBRARY:LIBRARY-FUNCTION

While executing: CCL::USE-PACKAGE-1, in process Listener(117).
Type :GO to continue, :POP to abort, :R for a list of available restarts.
If continued: Try again to use #<Package "LIBRARY"> in #<Package "COMMON-LISP-USER">
Type :? for other options.
1>

This is not that hard to recover from once you know what you're doing,
but it can be quite vexing for newcomers.

rg
.

Relevant Pages

  • Re: why cl packages are hard to use ?
    ... How else would you recover from a situation where a typo at the REPL ... package is loaded. ... Undefined function LIBRARY-FUNCTION, in FOO. ...
    (comp.lang.lisp)
  • Re: use-package & name conflict: why they are not deferred?
    ... allowing to intern a harmful symbol to any package at any time by just ... Kaz, I see you know lisp very well, but I'd recommended to spend some ... which is declared not to be intended by lexicons. ... decorated as misc variants of "with-gensyms" macro. ...
    (comp.lang.lisp)
  • Re: why cl packages are hard to use ?
    ... Pascal Costanza wrote: ... combine two code bases that use the same package name. ... lexicons are immune from this because ... later on, package p1 removes foo from its export list, but p2 adds foo ...
    (comp.lang.lisp)
  • Re: Woohoo! My macros are now (semi) hygienic
    ... version had a critical bug in the AIF macro that will cause lexicons to ... which is a locked package: ... SBCL Manual, Package Locks ...
    (comp.lang.lisp)
  • Re: PKG: Lexicons-killer read macro.
    ... ;; symbols interned in surrounding package overriden, no conflicts: ... lexicons must be getting traction if you feel the need to write a ...
    (comp.lang.lisp)