[Ecls-list] compile-file-pathname bug

[Gabriel Dos Reis]

Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> writes:

| On Wed, May 13, 2009 at 1:28 AM, Gabriel Dos Reis <gdr at cs.tamu.edu> wrote:
>>
>> Hi,
>>
>>  I believe ECL has a bug in its implementation of compile-file-pathname.
>> More specifically, my reading of the CL spec suggests that the form
>>
>>   (compile-file-pathname "foo.lisp" :output-file "foo.fas-tmp")
>>
>> should yield a pathname P#"foo.fas-tmp".  However, ECL produces
>> P#"foo.fas".  I think that violates the CL spec.
>
| I am afraid that you are imposing some interpretation onto the
| specification. ECL is self consistent. The definition of
| compile-file-pathname says "Returns the pathname that compile-file
| would write into, if given the same arguments.", while the definition
| of compile-file says "output-file can be used to specify an output
| pathname; the actual pathname of the compiled file to which compiled
| code will be output is computed as if by calling
| compile-file-pathname. "

Well, my interpretation is based on this provision in the spec:

   The defaults for the output-file are taken from the pathname that
   results from merging the input-file with the value of
   *default-pathname-defaults*, except that the type component should
   default to the appropriate implementation-defined default type for
   compiled files.

Since in the :output-file I specified, I did not leave out the default
for the file type, there is no room for the implementation to impose its
own default.

All of the free implementations I tried (CLISP, SBCL, GCL, ABCL) honor
my choice of file type.  Only ECL does not.

>
| There is a historical reason for ECL not honoring your choice of
| output file which is that the user's choice of file extensions might
| not be appropriate: if you specify a file extension that ECL does not
| understand as binary it will refuse to load your file.

I understand that; but I believe ECL could be improved there too.  For
example, if the file extension is not one that is listed for input Lisp
source files (e.g. .lisp), then ECL could attempt to load it as a FASL.

| Now the question is, should I really apply the change?

At the moment ECL seems to the only free implementation that refuses to
honor user-supplied file extension.  That in particular (among other
things) excludes ECL as a bootstrapping Lisp system for SBCL.  That
would be OK, if the benefits far exceed the drawbacks.  However, I do
not think we have enough compeling reasons for ECL to stay in that state.

-- Gaby