[slime-devel] Re: recording and compiling changed definitions

[Marco Baringer]

Helmut Eller <heller at common-lisp.net> writes:

> * Marco Baringer [2007-04-09 13:08+0200] writes:
>
>>>
>>> This is something that the compiler should do, not the editor.
>>
>> How can the compiler know what we've edited and what we haven't?
>
> So called "incremental" compilers know that.  That's pretty common in
> the Java world.  I think the GNU Ada compiler also has support for
> incremental compilation.  The Fun'O Dylan and the SML/NJ compiler
> too.  Those compilers usually keep the AST, compilation environment, or
> some fingerprints of the previous compilation in memory or save it to
> a DB.

i'm sorry, but i fail to see how that is possible without having the
editor (be it emacs or something embedded in the compiler) tell the
compiler what text has been written/edited and what hasn't.

or do you mean we should save all the files and then tell the compiler
to re-read them all and infer what needs to be done? if that's what
you're saying then i'd still like this feature if just for the emacs
buffer listing the changes before the source code (which may or not be
valid) is read/compiled.

>> Or are you just saying that we should be using the compiler and not
>> pxref to compute the compile order?
>
> I'm saying that the compiler (or related program transformer) is
> better suited to implement this feature than the editor.  I'm pretty
> sure that Franz' ELI does this stuff on the Lisp side.

the emacs side of eli keeps track of what files have been modified and
passes the original and the new version to allegro who'd then do a
smart diff. what i'm suggesting here is a slightly smarter version of
that, why bother diff'ing if we can learn what's different as the
changes get made?

> As far as I can see, this feature tries to work around slow compilers.
> Why not fix the compiler instead?

this feature serves two purposes:

1) make emacs keep track of all the code i've edited since the last
   compile. even without actually being able to compile the code i
   find the list-changed-forms buffer very useful. often i'll be
   working on a single piece of functionality which is speard across
   multiple files (one file has the db class definition, another the
   corresponding xml-api implementation and a third has the core code
   itself) it's a pain to remeber all the pieces i've touched. maybe
   i've saved the buffers, so i can't just use buffer-modified-p,
   maybe i haven't saved the buffers, so 'svn stat' doesn't help,
   maybe i've edited the documentation and i don't care about those
   files. in this case it really is nice to ask emacs for a list, in a
   single buffer, of all the lisp forms i've been working on
   rencently.

   being able to order and compile these forms is really just icing on
   the cake. i could just as well walk down the buffer and hit c on
   each form to compile them manually in whatever order i want.

2) work around projects where build times are 20 minutes or more. you
   can only speed up the compiler so far, some projects are just big
   and there's nothing you can do about it.

now, having said all that there's no way, given an arbitrary set of
changed lisp forms and an arbitrary set of existing definitions in the
image, to properly infer what order they need to be compiled in
without compiling and executing them. this last step is going to error
if you get the order wrong, since you have to this to get the ordering
right you're screwed in the general case. in practice the 80% solution
is helpful, but i'll drop if it seems like bloat.

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
	-Leonard Cohen