| Date: Sun, 27 May 2007 14:38:14 -0700
| From: "Joe Marshall" <jmarshall at alum.mit.edu>
|
| On 5/27/07, Aubrey Jaffer <agj at alum.mit.edu> wrote:
| > | Date: Sat, 26 May 2007 11:58:47 -0700
| > | From: "Joe Marshall" <jmarshall at alum.mit.edu>
| > |
| > | On 5/25/07, Thomas Lord <lord at emf.net> 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 #_at_nil)
; in top level environment.
;STACK TRACE
1; (#_at_bar foo 4 #_at_nil)
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.
Received on Mon May 28 2007 - 22:35:56 UTC