Re: [Scheme-reports] Formal Response #382: Allow "if" to accept arbitrarily many if-then pairs Aaron W. Hsu 13 Oct 2012 02:35 UTC

On Fri, 12 Oct 2012 00:07:23 -0400, John Boyle
<johnthescavenger@gmail.com> wrote:

> As you show, it is possible to define "if" to be used at compile-time,
> but
> this is not satisfactory because the macros I proceed to define, using
> if,
> will not be usable at compile-time to define a third set of macros.  I
> could (for-syntax <define the second set of macros>), which would make
> them
> available at compile-time, but that would not succeed because "if" does
> not
> have the right definition at phase 2 (used when defining macros for
> compile-time).  This could be fixed by (for-syntax (for-syntax <define if
> the way I want>)).  However, if I wanted to define more macros that
> depended on the third set, I would need to (for-syntax (for-syntax
> <define
> second set of macros>)), and (for-syntax (for-syntax (for-syntax <define
> if>))).  And so on.  I considered some schemes like defining a
> "define-macro" procedure that would write all previous definitions to a
> file and require it (for-syntax), but decided this was getting
> ridiculous--these are the insane workarounds I mentioned.

Depending on the system you are using, I believe that all Scheme systems
with either explicit or implicit phasing and proper module systems can
handle the code you are trying to write (more on that later), but I think
there is no explicitly standard way to do this with any Scheme report.

> The "meh" macro was just a test case to illustrate the problem.  As I've
> said, I want to define a bunch of macros, any of which might be defined
> in
> terms of previous macros--and functions, though macros is already hard
> enough.  My intent is to port as many as possible of the various
> convenience macros from Arc to whatever Lisp I'm currently using, and to
> do
> it as conveniently as possible.  The ideal test case defines the
> macro-defining macro "mac" (equivalent to defmacro), uses it to define
> the
> function-defining macro "def", uses "def" to define list-manipulating
> functions like "tuples", uses "mac" to define the macro "if" somewhere
> along the way (possibly using "tuples"), uses "mac" and "if" to define
> the
> gensym-binding macro "w/uniq", uses "mac" and "if" and "w/uniq" to define
> the destructuring binding macro "let", uses "mac" and "if" and "let" to
> define the binding macro "with", ...

While the idea that a system should be able to handle arbitrary macro
phases going up to a possible non-static number of degrees is not a bad
thing to desire, and Scheme systems like Chez Scheme definitely support
this (I suspect that Racket has a way of doing this as well), allow me to
be so bold as to suggest that your approach is flawed in this instance.

Specifically, I don't see any reason so far for using a DEFMACRO style
facility here. Actually, in R6RS or any system with SYNTAX-CASE, there
*is* no reason for using a DEFMACRO style macro system. Any reliable set
of Scheme macros should be written in a completely hygienic style, and
this is much more easily achieved using syntax-rules and syntax-case, both
of which are standard Scheme. They will result in more reliable macros,
and it's worth learning how to use those facilities.

Moreover, it doesn't look like you need an arbitrary number of phases. I
haven't finished going through your file, but I think that you can get
away without needing those dirty tricks that you mentioned, or even more
than, at most, 2 meta levels.

--
Aaron W. Hsu | arcfide@sacrideo.us | http://www.sacrideo.us
Programming is just another word for the Lost Art of Thinking.

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports