Re: [Scheme-reports] Formal Response #382: Allow "if" to accept arbitrarily many if-then pairs
John Boyle
(12 Oct 2012 02:11 UTC)
|
Re: [Scheme-reports] Formal Response #382: Allow "if" to accept arbitrarily many if-then pairs
Aaron W. Hsu
(12 Oct 2012 02:17 UTC)
|
Re: [Scheme-reports] Formal Response #382: Allow "if" to accept arbitrarily many if-then pairs
Sam TH
(12 Oct 2012 02:17 UTC)
|
Re: [Scheme-reports] Formal Response #382: Allow "if" to accept arbitrarily many if-then pairs
John Boyle
(12 Oct 2012 04:07 UTC)
|
Re: [Scheme-reports] Formal Response #382: Allow "if" to accept arbitrarily many if-then pairs Aaron W. Hsu (13 Oct 2012 02:38 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