Re: [Scheme-reports] Formal Response #382: Allow "if" to accept arbitrarily many if-then pairs

["Aaron W. Hsu" <arcfide@x>]

On Fri, 12 Oct 2012 00:07:23 -0400, John Boyle  
<johnthescavenger@x> 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@x | http://www.sacrideo.us
Programming is just another word for the Lost Art of Thinking.

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