Ticket #1020 (closed defect: invalid)

Opened 19 months ago

Last modified 19 months ago

CL:LOAD improper behavior

Reported by: ryanhope Owned by:
Priority: normal Milestone:
Component: ANSI CL Compliance Version: 1.8
Keywords: Cc:


cl:load should bind cl:compile-file-pathname to NIL but it does not, this causes the following to break:

(eval-when (:compile-toplevel :load-toplevel)

(asdf:load-system :iolib))

Change History

comment:1 Changed 19 months ago by gb

  • Status changed from new to closed
  • Resolution set to invalid

I assume that you're talking about CL:*COMPILE-FILE-PATHNAME*, but that's just a guess; I honestly don't know what you're talking about.

As I read the spec's description of LOAD and of *COMPILE-FILE-PATHNAME*, someone should be able to write code like:

;;; file "a.lisp"
(eval-when (:compile-toplevel)
  (load "b.lisp"))

;;; eof

;;; file "b.lisp"
(eval-when (:load-toplevel :execute)
  (print *compile-file-pathname*))

;;; eof

(compile-file "a.lisp")

and expect to have a non-NIL pathname printed. (This example is intentionally implausibly simple, but that doesn't seem to make it less legitimate.)

You're suggesting that someone shouldn't be able to write code like the above and expect that result, even though the spec says quite clearly that they should. I have no idea why you think that valid code should break so that your example should work as you expect it to, but would guess that if ASDF:LOAD-SYSTEM or whatever happens during the loading of IOLIB doesn't want to run if the non-NIL value of *COMPILE-FILE-PATHNAME* indicates that the loading is happening within the dynamic extent of a call to COMPILE-FILE, there's likely a good reason for that.

comment:2 Changed 19 months ago by fare

Nitpicking, but it is also always wrong to use (:compile-toplevel :load-toplevel) without :execute, so the bug reporter will lose when someone loads his file as source (or uses load-source-op or asdf-dependency-grovel, which will).

If you want cl:*compile-file-pathname* bound to NIL, you can use (let ...), or setf.

Is the real problem that you were compiling a system with error, then re-entered asdf:load-system from the debug prompt, leaving variables bound as if you were still compiling the file that had a bug? If that's an issue, you should unwind the debugger.

But maybe indeed asdf should bind various things to NIL when it compiles or loads stuff.

comment:3 Changed 19 months ago by ryanhope

  • Status changed from closed to reopened
  • Resolution invalid deleted

comment:4 Changed 19 months ago by rme

I think that you may be reading something into the spec that is not there. I myself don't see anything in the bit of the spec you cite that supports your assertion that cl:load should bind *compile-file-pathname* to nil.

Can you possibly give a different example that shows what you think is wrong here that doesn't involve ASDF and iolib? Do you agree that with Gary's example files, (compile-file "a.lisp") should print a pathname and not nil?

comment:5 Changed 19 months ago by gb

  • Status changed from reopened to closed
  • Resolution set to invalid

In all of the implementations that I tried my example in (CCL, LispWorks?, SBCL, Clisp, and Allegro), a pathname was printed.

This isn't definitive, of course: all of these implementations could have gotten this wrong and the reporter gotten it right.

Given how simple and unambiguous the phrase "during a call to COMPILE-FILE" is, that seems extremely unlikely. In fact, it seems like a phrase that requires minimal effort to understand.

Please make that effort.

Note: See TracTickets for help on using tickets.