[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 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.

ECL is not alone in that position -- SBCL is also used for scripting.
I know it is hard to live with history.  But, to allow for scripting, it
would have been natural for ECL to required that an ECL script has some
extension (e.g. .ecl?).

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

Yes; that does not contradict what I proposed.

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

Yes, but:
  (1) source binaries tend to have some popular extensions -- just
      document the one ECL supports and be pragmatic about it
  (2) anything else will be treated as binary -- be pragmatic about it.

I do not think ECL is unique in this position. 

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

A data point here is that ECL seems to be unique (among the 5 free
implementations I've tried) to impose that.  So, it looks like a popular
unrealization... 

>
| What I say is that there is no escape out: a means of identifying the
| type of a file is needed. 

Yes -- I believe we all agree on that.

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

Indeed.  An underlying question is to what extent ECL really wants to be
agnostic to the file content.

-- Gaby