On Sat, Feb 5, 2011 at 5:18 PM, Faré fahree@gmail.com wrote:
On 5 February 2011 11:13, Juan Jose Garcia-Ripoll juanjose.garciaripoll@googlemail.com wrote:
On Sat, Feb 5, 2011 at 4:06 PM, Faré fahree@gmail.com wrote: Fare, could you please go back to the other method I posted. This one
does
not allow one to *CHANGE* the way COMPILE-FILE* behaves.
Do you need to change it dynamically? Why not just have a static #+ecl or something? don't understand the use case.
Yes, it has to be changeable if the user decides to switch compilers, for whatever reason. To name one, Windows users will get by default a bytecodes compiler shipped in, and will have to switch to the lisp->C compiler at run time if they have MSVC around (which is rarely the case). And the converse should be possible: Linux users could have lisp->C preloaded and switch to bytecodes compilation for a session. All this should be doable with the same ASDF image.
As you see, it would even be better to have a global variable ASDF:*COMPILE-FILE-FUNCTION* specify who does what instead of having us mess with function definitions.
Since all this is ECL-specific (so far), I suppose you could use ADVISE, or whatever ECL-specific hooking mechanism exists, or delete-method calls.
But do you realize, that precisely because this is very ECL specific, there is no need to complicate COMPILE-FILE* and the way we have to interfere with it.
Design of ASDF should expose only a minimal, well thought out API. Making COMPILE-FILE* a generic function, when the types of arguments is fixed, just for the sake of :AROUND methods is absurd. It forces non portable code (I call MOP nonportable) just to change/delete a feature.
If you want me to put it another way. The patch I submitted was just to get rid of an :AROUND method, and you just forced me to add another one + MOP code in my own system.
Please, reconsider this,
Juanjo