[alexandria-devel] eval-always, defun-always, etc...

[Michael Weber]

On Oct 16, 2009, at 12:30 , Faré wrote:

>>> : Michael Weber <michaelw+alexandria at foldr.org>
>>> Don't add any of these kludges, and instead reorganize code such  
>>> that
>>> EVAL-WHEN is not sprinkled throughout the code.
>
>> : Attila Lendvai <attila.lendvai at gmail.com>
>> IOW, you propose that the current way of categorizing definitions  
>> into
>> separate files should be changed so that it is based on evaluation
>> stages.
>>
>> this is certainly a cleaner solution in some ways, but it also means
>> that for example if an ensure-car is used in a macro in the same
>> module, then it must be moved from lists.lisp to
>> compile-time-stage.lisp.
>>
>> i would even be ok with that, but it's not any less kludgy from
>> another point of view.
>
> It would be extraordinarily kludgy, especially for functions
> that are just MEANT to be used by macros. Why require them
> to be in a different file from the macros that use them, or cause
> the file in which they are to be loaded in a special way?
> That a macro uses a defun instead of an flet should be an
> implementation issue not exposed to the users of the macro,
> who shouldn't have to know that "hey, for this file, we should
> use the FASL, not the CFASL", just because of how the author
> (failed to) organize the internals of his files.

Fare,

I think some meaning got lost in Attila's snipping/interpreting of  
what I said.

I proposed phase segregation (basically because things get hairy down  
the line when not thinking about that from the start) based on files.   
However, I ALSO said that code should be wrapped in EVAL-WHEN:

>> all code that's needed in the compilation stage goes into files  
>> separate from run-time code, with only one EVAL-WHEN per file.


As for Attila's ENSURE-CAR use case, I see at least two options:

1. duplicate the code of small utility functions for the compilation  
stage.  I don't really see this as a big problem, as code used in  
macro processing/s-expression frobbing is not likely to pull in  
significant code bases, say, a webserver/http-client, etc..  It also  
avoids pulling all the other lists.lisp stuff if that is not needed.

2. if more of lists.lisp (or other modules) would be used in "foo- 
macros.lisp", there must be a way to have the latter file depend on  
the former for the compilation stage.  Otherwise, how would you solve  
this for xcvb now?

(FWIW, there are Scheme module systems which enforce phase separation;  
ObReference:
Matthew Flatt, Composable and Compilable Macros, <http://www.cs.utah.edu/plt/publications/macromod.pdf 
 >)

-- 
Cheers,
Michael