On Mon, May 18, 2015 at 7:27 AM Jonathan S. Shapiro <s...@eros-os.org> wrote:
> 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. > In the interest of waffling, an interactive top level is extremely compelling to me too, so an explicit letrec is good for that reason. > 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 > bitc-dev@coyotos.org > http://www.coyotos.org/mailman/listinfo/bitc-dev >
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
