From: John K. Hinsdale <hin@al...> - 2002-09-20 01:14:18
> Suppose you compiled file "foo.lisp" with an older CLISP (so that
> "foo.fas" has obsolete bytecode) and tell a new CLISP (LOAD "foo").
> What should CLISP do?
I would behave consistenly with other compiled languages (e.g., say
an caused compiling "C" changed from 'a.out' to 'ELF') and either
- support the old object format in a backward compatible way;
(which is not really an option here to do effort/rewrd)
- signal an error.
So I guess I am saying signal an error. To recompile automatically,
even with a warning, is to proceed in a mode (probably much slower)
and give the user "almost working" behavior, and possible a little
puzzle to have to solve why things got slower.
In other words, unless there is an announced change in the
functionality of CLISP (not the format) I'm arguing that he (the user)
should get exactly the behavior he had before, including the
performance of compiled modules.
That is just my knee-jerk one-minute response. Perhaps there is a
middle ground of "automatically recompile, but only if an option is
set" and then we can argue about what should the default for that
option be :)
John Hinsdale, Alma Mater Software, Inc., Tarrytown, NY 10591-3710 USA
hin@... | http://www.alma.com/staff/hin | +1 914 631 4690
> Now it sees that there is no file "foo", so it looks in *LOAD-PATHS*
> for "foo.lisp", "foo.fas", "foo.cl" and "foo.lsp" and tries to load the
> newest of the found files, i.e., "foo.fas", and then signals an error.
I don't even like that.
I hope at least if you (load "foo.fas") it doesn't look for foo.lisp, etc.
> - issue a warning instead and load "foo.lisp"
> - also delete "foo.fas" so that the next time there will be no warning
> (and a `make' will recompile "foo.lisp")
> - recompile "foo.lisp"
just as bad as delete
> A warning + optional removing the bad file appears to be the safest way.
I think it should be an error. Make it a new subclass of error
(sublcass of file error?) so anyone who wants to can handle it as he