On 5/27/07, Aubrey Jaffer <[EMAIL PROTECTED]> wrote: > | Date: Sat, 26 May 2007 11:58:47 -0700 > | From: "Joe Marshall" <[EMAIL PROTECTED]> > | > | On 5/25/07, Thomas Lord <[EMAIL PROTECTED]> wrote: > | > There's nothing especially new about the proposals. > | > | Nope. And that's part of the problem. > | > | Both FEXPRs and first-class environments make it extremely > | difficult to reason about the behavior of a program. With FEXPRs, > | you simply cannot tell whether any particular instance of a > | function call is going to be a special form or not. It might be > | applicative order this time, normal order next time. Every year or > | two someone tries to re-introduce fexprs. People point out the > | problems and the person ignores them and tries anyway. He comes > | back a month or so later and says ``Well, I got them working, but I > | can't figure out how to compile...'' > > SCM has been using FEXPRs without the difficulties you mention since > 1992. In interpretation, each FEXPR form is replaced by the code it > expands to the first time that form is evaluated.
I'm guessing that we aren't quite talking about the same thing. I couldn't find any documentation on FEXPRs in SCM, so I'm not quite sure what the semantics are. What I am talking about is first-class functions that don't evaluate their arguments. For example, in this code: (define foo (flambda (x y) `(list ',x ',(- y 3)))) (define bar (lambda (f a b) (f (+ b 2) a))) (bar cons nil 4) => (6) (bar foo 4 nil) => ((+ b 2) 1) foo is our fexpr, and when we pass it into bar, the subform (+ b 2) is passed rather than the value. > Both the Hobbit (http://swiss.csail.mit.edu/~jaffer/hobbit_toc.html) > and Schlep (http://swissnet.ai.mit.edu/~jaffer/Docupage/schlep.html) > compilers expand all defmacros before analyzing the code to be > compiled using the SLIB function DEFMACRO:EXPAND* > > `(require 'defmacroexpand)' > > -- Function: defmacro:expand* e > Returns the result of expanding all defmacros in scheme > expression E. I expect that this is different from what I was talking about because the form cannot be expanded before runtime because the procedure isn't applied. In this paper: @inproceedings{ bawden00firstclass, author = "Alan Bawden", title = "First-Class Macros have Types", booktitle = "Symposium on Principles of Programming Languages", pages = "133-141", year = "2000", url = "citeseer.ist.psu.edu/bawden00firstclass.html" } Bawden points out that if you know a bit about the macros, like what sections of code they intend to retain as code and what sections they intend to manipulate as list structure, you can recover the compilability, but I don't know of a Scheme system that has taken this approach. I have to confess that I making assumptions about what Tom Lord proposes as FEXPRs, so if I have that wrong, I'm obviously arguing a bogus position. -- ~jrm _______________________________________________ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
