[Openmcl-devel] COMPILE-FILE maybe-bug

Tim Bradshaw tfb at tfeb.org
Wed Sep 29 15:33:09 PDT 2010

On 29 Sep 2010, at 23:02, Gary Byers wrote:

> 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 think one problem is defining what "user level code" is.  The specific case here is ASDF, but there is a very fuzzy boundary - what about code that provides networking, say?

More generally anywhere where a package might or might not be present for code that's being compiled then by far the easiest way to ensure that that code can even be read is #+feature-expression (package-that-may-exist:foo ...).  Even more so for code that provides differing syntax, of course.

> 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))

I'm pretty sure that the most recent patch I sent will work with this.
> 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 think what you must mean is "modify at all" rather than "modify at load time"?  I can't think of any other time when it's useful to modify it.  Well, I think the underlying thing that needs to be sorted out is that at the moment it is fairly easy to build systems with CCL which have consistency problems: for instance you can end up with something which exists in *MODULES* but which has failed to get things into *FEATURES* which it wanted to be there, and this means that REQUIRE will now not load it, which in turn may mean there is no easy way of getting it loaded at all.  That is precisely what is happening with the IDE at the moment.

More information about the Openmcl-devel mailing list