[Openmcl-devel] COMPILE-FILE maybe-bug

[Gary Byers]

I haven't paid careful attention to this and am operating with
dangerously low caffeine levels, but my first reaction is to think
that user-level code shouldn't be persistently modifying *FEATURES* at
all.  (In other words, if the act of loading the file "FOO" causes
:FOO to appear on *FEATURES* ... well, :FOO doesn't seem to be an
aspect of the implementation, and it's not an aspect of the
environment in anything like the sense that :LINUX is.  I'll try to
think about it again with more caffeine in my system,  but my model
is that the implementation decides what's on *FEATURES* and user
code doesn't use it as a means of advertising its presence.)  (And
of course conveniently forgetting dozens of counterexamples is one
of the symptoms of caffeine deprivation.)

It's somewhat common/useful for code to do things like:

===========
(eval-when (:compile-toplevel)
   ;; Canonicalize some features to simplify conditionalization
   #+(or imp-a imp-b ...) (pushnew :native-threads *features*))

...

#+native-threads ...
#-native-threads ...
===========

within a file, but I can't think of cases where that kind of 
change to *FEATURES* is intended to be a persistent, load-time
thing.

Limiting the extent of compile-time changes (by binding *FEATURES*
in COMPILE-FILE) is intended to minimize the possibility of conflicts
when compiling different systems in the same environment; it also
supports an extenstion to COMPILE-FILE:

(compile-file ... :features '(:native-threads))

which probably looked like it'd be more useful or widely-used than
it's been in practice.  That was done in MCL > 20 years ago, and 
I'm fairly sure that the case of someone doing:

(eval-when (compile)
   (require "file-which-modifies-features"))

would have been considered and dismissed ("user code shouldn't
modify *FEATURES* at load time.")

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.

On Wed, 29 Sep 2010, Tim Bradshaw wrote:

> On 29 Sep 2010, at 13:52, Tim Bradshaw wrote:
>
>>  I am not sure of the thread-safety issues of this: *features* will *globally* have a new value while COMPILE-FILE is running.
>
> Sorry, another followup to myself.  The above is not necessary at all, and the below patch deals with that.
>
>