On Oct 16, 2009, at 12:30 , Faré wrote:
: Michael Weber michaelw+alexandria@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@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
)