[Ecls-list] compile-file-pathname bug

[Gabriel Dos Reis]

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

| On Sun, May 17, 2009 at 12:24 AM, Gabriel Dos Reis <gdr at cs.tamu.edu> wrote:
>> Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> writes:
>> At the moment, ECL's target for dynamically loadable modules fall into
>> three camps: ECL, PE, MACH.  Please correct me if that list is short.
>
| Please note the following answer: I do not know. I do not need to.
| That is the beauty of how things are implemented right now. I only
| care about the API provided by the operating systems we support, not
| by the details of the binary files -- as opposed to, say, GCL, which
| implements the binary loader itself again.

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

That way, you'll care only about the ABI provided by the opertating
systems. 

>
>> I suspect I did not make myself clear.  My understanding of your
>> explanation of forcing '.fas' and not letting the user chose his own is
>> that, that way the system 'knows' that a file with '.fas' extension
>
| Well, in this case _I_ was not clear enough. This is my reasoning. If
| we do not have the magic for detecting types of files, then the only
| two alternaives are either associate the file types with the
| extensions or first try binary and then source. Since the latter was
| problematic -- it injects arbitrary files into the binary loader
| provided by the OS with the problems I mentioned before -- I removed
| that and stayed with the first.

I suggested the magic number only in case you wanted to do some preliminary
validation of the contents before handing the file to the operating system.  
But if you don't need to do that validation (current situation), then
you don't need the magic number; but, you can still provide the ability
for user to chose their own extensions for the output file.


>
>> it is not a problem
>> you can solve by forcing a particular extension even when the user
>> wanted a different one.  The simple reason being that the extension does
>> not make the content OK and the content is the problem.
>
| Sure, but we are back to the same place: either we have a function
| that does what 'file' does for Unix and we know all the binary formats
| we support, or we do something simpler and associate types with
| extensions. 

I'm not sure it is a binary question.  
In my view, there is room for grayscale.
ECL would need to do the equivalent of 'file' only if it wanted to do
some preliminary validation before calling the operating system
functions.  But, if you don't want that (as is currently the case), then
you don't need it. 

And as I showed in previous message, imposing the '.fas' does not solve
the problem.

| In the first case someone has to code it, in the second
| case, if I really want to use a particular extension, then configuring
| ECL is not that hard:
>> (push '("myfas" . SI::LOAD-BINARY) si::*load-hooks*)
>
| (("myfas" . SI:LOAD-BINARY) ("fasb" . SI:LOAD-BINARY) ("fas" . SI:LOAD-BINARY)
|  ("fasl" . SI:LOAD-BINARY) ("lsp" . SI:LOAD-SOURCE) ("lisp" . SI:LOAD-SOURCE)
|  ("LSP" . SI:LOAD-SOURCE) ("LISP" . SI:LOAD-SOURCE) ("fasb" . SI:LOAD-SOURCE)
|  ("FASB" . SI:LOAD-SOURCE) (NIL . SI:LOAD-SOURCE))

Now, we are back to ECL having a unique behaviour for compile-file-pathname
compared to other free Lisp implementations.
In terms of portability, I'm not sure we will check the box for ECL here.

And I could insert the standard rants about #ifdefs here :-)

-- Gaby