On Sat, Feb 5, 2011 at 5:18 PM, Faré <fahree@gmail.com> wrote:
On 5 February 2011 11:13, Juan Jose Garcia-Ripoll
> 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

--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com