WhyOrderMatters - larcenists/larceny GitHub Wiki

This page is dedicated to documentation of why sometimes the order of elements in some definition is actually significant even though you might not realize so.

• Lib/makefile.sch: The common-heap-files definition lists all the components that we will load in the bootstrap heap. We actually run the code for each in order. So if one file uses a variable defined by another file, you better make sure you get the order right.
  • This matters because, for example, if you try to define a macro in Compiler/usual.sch that uses a transformer macro, you'll get the mysterious error on startup that no callout vector is defined.
  • The reason this happens is that the expander is going to call eval on a transformer macro, and not only has eval not been defined, but the error handling machinery for telling you that eval is undefined hasn't even been set up yet.
  • The current strategy for dealing with this (that is, for making a transformer macro that is part of the "standard" distribution) is to arrange things so that we delay the macro definition until after all of our machinery has been setup. We do this by pushing a quoted macro definition onto the variable *interactive-eval-list*.
  • Note however that *interactive-eval-list* is defined in Lib/Common/toplevel.sch, which occurs relatively late in the order defined in Lib/makefile.sch. (Agh! Order matters!) So you need to make sure that if you're going to use this trick, that you only do it in heap files that are loaded after "toplevel"