[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Whether interpreted&compiled code should agree initially?
- To: COMMON-LISP%SU-AI@SCORE
- Subject: Whether interpreted&compiled code should agree initially?
- From: Rem@IMSSS
- Date: Fri, 12 Oct 1984 01:42:00 -0000
Date: 11 Oct 84 20:01 PDT
I certainly don't want to take on the task of deciding how far to
standardize the solidarity between interpreted code and compiled code.
This reminds me. The old approach was that some "programs" would run
differently interpreted from compiled, mostly due to interpreted
variables defaulting to special while compiled variables defaulting to
local, but such programs with undeclared free variables weren't
regarded as "correct" LISP programs even though they ran ok
interpreted. Software existed (for example FCHECK for USLISP and PSL)
to look for undeclared free variables and other problems, so the
programmer could repair the code to be "correct", so that it would run
the same interpreted and compiled (more likely so it would compile at
all). A program wasn't considered finished until FCHECK or whatever
failed to find any source errors.
Common LISP has taken a different tack. At great pain interpreted code
is made to act like compiled code, so that trouble is found during
interpreted test runs rather than later during FCHECKing or attempts
at compiling. Does anybody have strong reason why this method is
better? (I always thought the purpose of a LISP interpretor was to be
able to hack together something which while not correct did run enough
that I could debug the various parts of it independently rather than
have everything break if one declaration early in the file was
missing. Then after getting it to basically work you start tuning it
to run more efficiently, i.e. compiled at all, and maybe with some
variables used in tight loops declared as FIXNUMs or BOOLEAN or (ARRAY
<const> <const>) etc. Doesn't Common LISP sort of go against the
hacking philosophy?) Why not allow interpreted and compiled code to
have different semantics for initial versions of programs that aren't
yet correct, but provide software for checking the correctness of
programs so they can be made to run the same both ways??