Helmut Eller heller@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.