[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Questions about specification and possible implementations
- To: PERDUEfirstname.lastname@example.org
- Subject: Questions about specification and possible implementations
- From: Skef Wholey <Wholeyemail@example.com>
- Date: Tue, 09 Oct 1984 21:11:00 -0000
- Cc: Commonfirstname.lastname@example.org
- In-reply-to: Msg of 8 Oct 1984 20:47-EDT from PERDUE%hplabs.csnet at csnet-relay.arpa
- Sender: WHOLEYemail@example.com
Ok, I retract that terminology. My point was that it's just as correct to
compile a keyword-taking function in a funny way as it is to open code CAR. If
a compiler is allowed to do the latter, it can certainly do the former.
JonL points out that this weakens the debugability of compiled code, since some
poor guy out there might want to trace CAR (or some other specially compiled
function) to find out what's going on. There are a few solutions to this
1. He can debug his code in the interpreter -- a problem if he's
already loaded a lot of compiled code. But anything calling itself a
Lisp environment should give the user a way to easily load the
interpreted definition of a few functions. This could be done in the
editor, or perhaps grabbing the interpreted definition if the compiler
had the foresight to save it someplace for him.
2. He can (PROCLAIM (NOTINLINE CAR)) and recompile the functions he's
interested in. If he doesn't suspect that a function is being compiled
in some funny way, he should be able to find out using DISASSEMBLE in
the worst case.
3. Common Lisp could provide a declaration or somesuch that would cause
the compiler to perform no special compilation of functions. When
debugging, one could still get something like compiled speed while
retaining full tracability. This would presumably be easier than
declaring everything you might want to trace NOTINLINE .
Making option 1 feasible in practice requires a good environment (read not
batch) -- not something part of the Common Lisp specification. Still, it isn't
that hard for an implementor to provide such tools. Option 3 requires a change
to the language specification, but is probably even easier to implement that
Option 1. Option 2 is the worst-case, current language spec option.
Anyone for (PROCLAIM '(ENABLE-INLINE T)) and (PROCLAIM '(ENABLE-INLINE NIL))?
With better names and syntax maybe?
Shades of (SSTATUS FOO T)... Gasp.