Joe Marshall wrote:
> 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.
They are called macros, in SCM. A subset of macros are
"memoizing" macros. These are classic old lisp-style macros
that take implicitly quoted arguments and return a form to
be evaluated. A "memoizing macro" is only evaluated
once, ever, per call-site (and then is replaced, permanently,
by the code it produces).
SCM doesn't have first-class environments at the user level
but they figure prominently internally. I forget whether
Guile has surfaced environments or not but Systas Scheme
did.
>
> 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.
Right. Fexprs. In SCM, that's:
(defmacro (foo x y) `(list ',x ',(- y 3)))
>> 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:
> _at_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.
>
>
In the *general case* you can't expand fexpr-style macros at
run-time however if you use them (along with first-class
environments) to implement conventional Scheme macros,
they should be expandable at compile time by constant
folding and similarly simple partial evaluation.
If you make careful use of first-class environments to implement
something like the PLT macro system, should should (using the
same kinds of tricks) be able to get separate compilation.
-t
Received on Sun May 27 2007 - 19:36:03 UTC