* Sam Steingold
| Erik's solution for the :key/#'reduce ACL problem starts with
| (in-package :franz) and ends with (in-package :user).
huh? it doesn't end with (in-package :user) in any version I can find
that I have posted. where did you get one that did?
the purpose of IN-PACKAGE is to ensure that symbols are interned in a
known package so the compiler can make certain optimizations and the user
of a file can live a less interesting life. it is not for interactive
use. (in Allegro CL, you use the top-level command :PACKAGE for that.)
you should just stuff my advice code in a file, perhaps compile it, and
then load it. it should not be prefixed onto other source code, which is
what it appears that you're doing. LOAD will bind *PACKAGE* across
loading, so it can be changed during loading. COMPILE-FILE will do the
same.
| what if I wasn't in :user?
the obvious solution is not to invoke IN-PACKAGE when you need the value
of the same binding of *PACKAGE* afterwards. which, again, LOAD takes
care of for you: you get the same binding of *PACKAGE* after LOAD as
before, because the one that may have been changed inside the loaded
object is a different binding.
matter of fact, (in-package :franz) does only a little more than
(eval-when (:compile-toplevel :load-toplevel :execute)
(setq *package* :franz))
which works because *PACKAGE* is bound by LOAD and COMPILE-FILE.
#:Erik
--
religious cult update in light of new scientific discoveries:
"when we cannot go to the comet, the comet must come to us."
* Sam Steingold
| I am highly reluctant to have yet another file. I have a special file
| with a bunch of system-specific stuff, like your reduce code,
| *gc-verbose* for CMUCL, *warn-on-floating-point-contagion* for CLISP etc.
| So, I guess, I should have asked about how to have your code in a file
| with a lot of other junk. Obviously, I can put it as the very last
| statement (right?), but I don't like it.
I fail to understand the charm of loading a file that could place symbols
and function definition into whatever package happens to be the value of
*PACKAGE* at the time of loading. why not always use IN-PACKAGE to make
sure you get all the stuff int the right packages? IN-PACKAGE can be
repeated in a file, since it affects the reader's behavior after it has
been evaluated.
#:Erik
--
religious cult update in light of new scientific discoveries:
"when we cannot go to the comet, the comet must come to us."
In article <··············@mute.eaglets.com>,
Sam Steingold <···@usa.net> writes:
> I do have an in-package in the beginning of the file.
> Nevertheless, the reduce thing has to be in a different package, so I
> have to either:
> 1. have a separate file for the reduce fix: a 10 line file? ugh.
> 2. put the reduce stuff at the very end of the file: ugly.
> 3. have 2 identical in-package in the file: one in the beginning and one
> right after reduce: ugly.
> is there another way?
>
> Thanks.
>
I'm not sure why you have such an aversion to files
but you could put the reduce code right before the
existing in-package form. Then you'd only have two of
them in your one file.
Mike McDonald
·······@mikemac.com
* Sam Steingold
| I do have an in-package in the beginning of the file.
conceptually, you should have an IN-PACKAGE in front of every top-level
form to ensure that symbols are interned in the right package, and
grouping several top-level forms in a single file with one IN-PACKAGE in
front of them all is just an optimization.
| 1. have a separate file for the reduce fix: a 10 line file? ugh.
| 2. put the reduce stuff at the very end of the file: ugly.
| 3. have 2 identical in-package in the file: one in the beginning and one
| right after reduce: ugly.
| is there another way?
I'm sorry, but I don't understand what the actual problem is. is this
about aesthetics, redundancy, or what?
when I build Allegro CL images, I have a whole bunch of files, custom.cl,
which only loads other files, which are compiled, including franz-fixes,
local-fixes, and local-extensions, as well as a site-init file that
tweaks a number of variables and package properties so Allegro CL comes
up without any visible CLtL1 compatibility, and some internal stuff that
somebody complained about some time ago: that DECLAIM doesn't just expand
to PROCLAIM forms within the appropriate EVAL-WHEN. here's how to fix
that minor annoyance:
(when (eq (excl::function-constant (macro-function 'declaim) 2) 'compiler::compiler-proclaim)
(setf (excl::function-constant (macro-function 'declaim) 2) 'proclaim))
I'm just showing this to illuminate why I don't quite understand your
point about two IN-PACKAGE forms being ugly... :)
#:Erik
--
religious cult update in light of new scientific discoveries:
"when we cannot go to the comet, the comet must come to us."
In article <················@naggum.no>,
Erik Naggum <······@naggum.no> writes:
> I'm just showing this to illuminate why I don't quite understand your
> point about two IN-PACKAGE forms being ugly... :)
>
> #:Erik
Well, one unfortunate thing about multiple IN-PACKAGE
forms is that Franz's Emacs interface only looks at the
first one. Whenever you evaluate one of the later
forms, it ends up in the wrong package. It'd be nice if
the eval commands would search backwords from the form
for a "^(in-package[\t ]*" line and use that package.
Mike McDonald
·······@mikemac.com
In article <····················@news2.teleport.com> ·······@mikemac.com
(Mike McDonald) writes:
> > I'm just showing this to illuminate why I don't quite understand your
> > point about two IN-PACKAGE forms being ugly... :)
> >
> > #:Erik
>
> Well, one unfortunate thing about multiple IN-PACKAGE
> forms is that Franz's Emacs interface only looks at the
> first one. Whenever you evaluate one of the later
> forms, it ends up in the wrong package. It'd be nice if
> the eval commands would search backwords from the form
> for a "^(in-package[\t ]*" line and use that package.
>
My Emacs Lisp shell does this and more. It works quite well and I've been
using it for many years now. Unfortunately, the code to do this is
intertwined with lots of other functionality in my Lisp shell and I don't
what to post the whole Lisp shell here. If you can't figure out how to do
this for yourself I could extract the pertinent code and give it to you if
you are interested.
--
William P. Vrotney - ·······@netcom.com
* Erik Naggum wrote:
* Sam Steingold
> | I am highly reluctant to have yet another file. I have a special file
> | with a bunch of system-specific stuff, like your reduce code,
> | *gc-verbose* for CMUCL, *warn-on-floating-point-contagion* for CLISP etc.
> | So, I guess, I should have asked about how to have your code in a file
> | with a lot of other junk. Obviously, I can put it as the very last
> | statement (right?), but I don't like it.
> I fail to understand the charm of loading a file that could place symbols
> and function definition into whatever package happens to be the value of
> *PACKAGE* at the time of loading. why not always use IN-PACKAGE to make
> sure you get all the stuff int the right packages? IN-PACKAGE can be
> repeated in a file, since it affects the reader's behavior after it has
> been evaluated.
I think I sent a mail message suggesting that one could do
(let ((*package* ...))
...)
which of course won't work, so how about this:
(defvar *package-stack* '())
(defun push-package (package/name)
(let ((package (typecase package/name
(package package/name)
(t (find-package package/name)))))
(push *package* *package-stack*)
(setf *package* package)))
(defun pop-package ()
(setf *package* (pop *package-stack*)))
Which should let you rebind packages suitably (though I guess you need
EVAL-WHEN around it).
--tim