On Sun, May 17, 2009 at 9:21 AM, Abdulaziz Ghuloum <[email protected]> wrote: > > On May 17, 2009, at 8:26 AM, Michele Simionato wrote: > >> This is the *last* episode about the module system: >> >> http://www.phyast.pitt.edu/~micheles/scheme/scheme24.html >> >> I will stop spamming this list with my Adventures now, promised! > > Something to ponder. You say: > Having compile-time effects affecting run-time values is evil, > since it breaks separate compilation. > > You're talking about inter-library side effects here, where a macro > in one library side effects, at expansion time, a value in another > library. > > What if we take the compilation/macro business out of the picture. > Say you have one library that, at initialization time, side effects > a variable/value "belonging" to another library. > > Would that be evil too? Justify your answer for full credit.
It is not a good idea to modify an object in another module just for the sake of it. However there are legitimate use cases for doing so. For instance debugging: suppose you add a before call hook to all of your functions, and that pre-call hook stores information about the function to be called on some global registry, and that there is a graphical debugger displaying the value of the registry and how it changes during the runtime of the program. Here is another use case: a documentation tool could extract information about you function definitions at compile time and store it in some temporary variable, which is then used to generate an HTML file containing the documentation. Another use case (I have already cited it) is an implementation of multimethods based on a global registry of functions. So yes, I think there use case when you really want inter-module side effects.
