| Date: Sun, 27 May 2007 14:38:14 -0700 | From: "Joe Marshall" <[EMAIL PROTECTED]> | | 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.
http://swiss.csail.mit.edu/~jaffer/scm_4.html#SEC64 Macro Primitives ---------------------- -- Function: procedure->syntax proc Returns a "macro" which, when a symbol defined to this value appears as the first symbol in an expression, returns the result of applying PROC to the expression and the environment. -- Function: procedure->macro proc -- Function: procedure->memoizing-macro proc -- Function: procedure->identifier-macro Returns a "macro" which, when a symbol defined to this value appears as the first symbol in an expression, evaluates the result of applying PROC to the expression and the environment. The value returned from PROC which has been passed to `PROCEDURE->MEMOIZING-MACRO' replaces the form passed to PROC. For example: (defsyntax trace (procedure->macro (lambda (x env) `(set! ,(cadr x) (tracef ,(cadr x) ',(cadr x)))))) (trace foo) == (set! foo (tracef foo 'foo)). `PROCEDURE->IDENTIFIER-MACRO' is similar to `PROCEDURE->MEMOIZING-MACRO' except that PROC is also called in case the symbol bound to the macro appears in an expression but _not_ as the first symbol, that is, when it looks like a variable reference. In that case, the form passed to PROC is a single identifier. -- Special Form: defsyntax name expr Defines NAME as a macro keyword bound to the result of evaluating EXPR, which should be a macro. Using `define' for this purpose may not result in NAME being interpreted as a macro keyword. | 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. > (defmacro foo (x y) `(list ',x ',(- y 3))) #<unspecified> > (define bar (lambda (f a b) (f (+ b 2) a))) #<unspecified> > (bar cons nil 4) (6 . #f) > (bar foo 4 nil) ;ERROR: Use of keyword as variable foo ; in expression: (foo 4 [EMAIL PROTECTED]) ; in top level environment. ;STACK TRACE 1; ([EMAIL PROTECTED] foo 4 [EMAIL PROTECTED]) So I think passing macros as arguments is not what Tom is talking about. | > 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. Defmacros written so that procedures defined in the same file are not called at expansion time are constrained such that expansion can always be done at read-time. In my experience, defmacro is capable of defining any syntactic transform that the more modern Scheme macros can. _______________________________________________ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
