So to clarify on this: I definitely think that the keywords for introducing top-level definitions should NOT be LET or LETREC. Personally they don't read well to me, but more importantly, the top-level introduction forms don't have an explicit end of scope. Where a LET[REC] binding goes out of scope at the end of the enclosed block, a top-level binding goes out of scope at the end of the file.
Historically, the main problem I have had with a LETREC-like construct for top-level mutual recursion is that it imposes a textual structure on the input that isn't always the best way to express the program. Textbooks like to look at the odd/even example, but in real code you often find that you have two or three mutually recursive procedures interspersed by various helper procedures. Personally, I find it clearer if the helper procedures are associated with (in my personal style: above) the procedure they support. If we adopt the LETREC-for-mutual-recursion view, then the helper procedures *also* need to be in the LETREC in some cases in order to support this textual style. The helper procedures usually don't want to be exported, so there is a purely syntactic question about where you should state what is exported if a top-level form introduces multiple identifiers. This can clearly be solved. In a lot of ways I agree with Geoffrey Irving on this one: let the compiler do this sort of work. The way to go about that would be to simply put *all* procedures in a given input unit of compilation into a common LETREC implicitly. There are some other languages that have done this. One problem with this approach is that we lose the "feel" of lexical scoping if any procedure can forward-reference any other procedure. A bigger problem is that it compromises our ability to implement an interactive top level. When any procedure can forward reference a later procedure, there are an awful lot of interactive inputs that cannot be compiled or even typed until the set of forward references is closed. In my opinion, the interactive top level issue is actually compelling, and I'm therefore going to go with an explicitly LETREC-like top-level introduction form. So to summarize: All forms that introduce procedures are implicitly a single-procedure LETREC. That is: procedures may generally be self-recursive without additional syntax. This is a case where the compiler can do the work of detecting self-reference; there is no need for separate forms to introduce recursive vs. non-recursive procedures. This is how BitC v0 works as well. There will be a distinct form, or possibly a variant syntax on the existing introduction form, to introduce mutually recursive procedures. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
