[Ecls-list] compile-file-pathname bug

[Juan Jose Garcia-Ripoll]

On Sun, May 17, 2009 at 1:03 AM, Gabriel Dos Reis <gdr at cs.tamu.edu> wrote:
> Oh, using the magic number is not necessary.  You can maintain still
> maintain the dichotomy by imposing that anything that has extension
>
>   * .lisp, .lsp (or some other popular documented Lisp source file
>     extensions) contains an input Lisp forms
>   * otherwise it is a FASL

The problem is that this also does not work. ECL used for scripting
must assume everything is by default source, not binary. As you say
this is not a black and white problem, but rather a problem of keeping
people's expectations -- and I can tell you I have found both.

Take for instance system definition files (*.asd). They are text, but
they have a nonstandard extension. I had to change ECL back then to
accept anything as source to allow these files to be loaded. I do not
know about other systems, perhaps Mudballs uses its own system
definition format.

The lousiness with which the specification is defined, imposes too
much flexibility, allowing for anything to be loaded means _both_
source and binaries might have any extension.

Until now I was relying on the fact that compile-file can, according
to the spec, impose its own file extension -- a fact that people do
not seem to realize --, as opposed to text files, which can be created
with any extension.

What I say is that there is no escape out: a means of identifying the
type of a file is needed. If it is not extensions it has to be magic
numbers, or some other tag we write at the end of binary files. In
some cases it is even impossible without some magic identification of
binary files: one could even open a binary file as a stream and pass
it to LOAD. This is also not supported by ECL.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28009 (Spain)
http://juanjose.garciaripoll.googlepages.com