On Sun, Sep 6, 2009 at 2:02 PM, Thomas Lord<[email protected]> wrote: > On Sun, 2009-09-06 at 13:38 -0700, Joe Marshall wrote: > >> No. The reason I oppose first-class environments is not *directly* >> because of efficiency and performance. >> >> I want to be able to reason about my code statically (that is, >> without running it). When I write lexical scoped code, I want >> to statically know what binding any particular reference refers to. >> First-class environments allow you to dynamically change the >> binding structure by inserting bindings where none existed before. > > (a) When you write *your* code, avoid capturing environments > and then you are all set. > > (b) It is not a foregone conclusion that f.c.e. means > arbitrary changes to binding contours.
I guess we'll first have to narrow down what we mean by `first-class environments' If you can only obtain a first-class environment by an explicit call to `the-environment', then you have fewer problems. But if you can call `procedure-environment' on any procedure, you've pretty much opened up the entire world. If you can eval `define' in a first-class environment, that can change the binding contours. If you wish to restrict how that works, then there are fewer problems. >> The reason the compiler cannot compile the code is because the >> code cannot be statically reasoned about. If the *compiler* can't >> reason about the code, a human has no hope. > > That's a load of crap, if you will please pardon the > expression. A compiler can reason thusly: "Ah, I see > that this has to be left to the run-time interpreter because > there is no optimized static representation of this code." I didn't mean the compiler couldn't defer to a runtime model. I meant that it *had* to punt to the runtime. That is, the compiler looks at the code and says ``Hmmm. Too dynamic, I got no clue, I'll compile this as `(eval ,code ,environment)'' > A human can reason principally by constructive induction > for many useful programs. They fail miserably when it gets complicated. -- ~jrm _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
