[Openmcl-devel] COMPILE-FILE maybe-bug
arthur.cater at ucd.ie
Thu Sep 30 02:15:53 CDT 2010
I agree with Robert, it can be useful to be able to push new features
on - at ANY time.
I understand it might be bad to remove implementor's features, or to
add features that
happen to mean something to the implementor, but if a list of those
were made available
then I think 'caveat emptor' should apply. The typical use surely is
to push totally new
features of one's own imagining, and there is no other mechanism
nearly as convenient
for conditionalising compilation. In my case, for instance, I have two
for a small subsystem, and something like asking a question - it
could be testing a
command-line flag or something else - allows switching between them
Maybe there are other ways to do this, but why deny me the use of
On Sep 29, 2010, at 11:32 PM, Robert Goldman wrote:
> On 9/29/10 Sep 29 -5:02 PM, Gary Byers wrote:
>> The fact that this is the first time that I remember user code
>> apparently trying to modify *FEATURES* at load time doesn't
>> mean much of anything, but coupled with the fact that doing
>> so seems like a bad idea my first reaction is to not want
>> to encourage user-level code to do that sort of thing.
> I'm actually having a hard time seeing a case where one would want the
> changes /not/ to persist, which shows how opinions can vary!
> E.g., when I worked on the Garnet code-base (a rapid-prototyping
> for UIs), it had a boatload of *features* that it set up in its loader
> to indicate facts about the target system.
> Let's say I compile and load Garnet. Then I find a bug. I jump to
> function, patch it, recompile the defun from emacs and .... get code
> that doesn't reflect the target platform any more.
> Having the changes not persist seems to fly in the face of the lisp
> notion of a dynamic development environment.
> Another case I just thought of: The new version of the ASDF system
> pushes :asdf2 onto *features* to indicate that system definers have
> available to them new features added since ASDF 1. Surely this should
> But maybe I'm failing to completely understand your argument....
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel