|
Fwd: Re: Invalid test case.
Marc Nieper-Wißkirchen
(21 Mar 2017 14:12 UTC)
|
|
Re: Re: Invalid test case.
Shiro Kawai
(22 Mar 2017 01:54 UTC)
|
|
Re: Invalid test case. Marc Nieper-Wißkirchen (24 Apr 2017 07:22 UTC)
|
|
Re: Invalid test case.
Shiro Kawai
(24 Apr 2017 11:45 UTC)
|
Please excuse the long delay. Could you please review the clarifications I added to the specification here: https://github.com/mnieper/srfi-147/blob/master/srfi-147.html If you think these changes are helpful, I will propose to incorporate the changes as an erratum to this SRFI because, technically, it is in fact an error not to mention `begin' explicitely. All the best, Marc Am 22.03.2017 um 02:54 schrieb Shiro Kawai: > Probably the confusion is that the use of 'begin' here isn't apparent of > being which one of three definitions of 'begin' in R7RS. > > 1. (begin <expression-or-defintion> ...) ; can appear as part of > <body>, outermost level of <program>, REPL, or inside (begin ...) of > this use > 2. (begin <expression> ...) ; can appear in <expression> > 3. (begin <command-or-definition> ...) ; as <library-declaration> > > I think the intention that it is begin #1 is implied in the "in order to > facilitate writing ..." paragraph, but it's not explicit that this > <macro use> is treated as if it consists of <body> (or, we could augment > R7RS 4.2.3 to say that begin#1 can appear in <macro-use> used as > <transformer-spec>). It's confusing because we get used to think begin > itself doesn't create a <body>. For example, Takashi's example > (define-syntax foo (begin (define bar 0) ...)) isn't symmetric to > ordinal definitions, where (define foo (begin (define bar 0) ..)) isn't > allowed. So it'll help to notify the reader that they are indeed different. > > > > On Tue, Mar 21, 2017 at 4:12 AM, Marc Nieper-Wißkirchen > <xxxxxx@nieper-wisskirchen.de <mailto:xxxxxx@nieper-wisskirchen.de>> wrote: > > > > > -------- Weitergeleitete Nachricht -------- > Betreff: Re: Invalid test case. > Datum: Tue, 21 Mar 2017 13:42:47 +0100 > Von: Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> > <mailto:xxxxxx@nieper-wisskirchen.de> > Antwort an: xxxxxx@nieper-wisskirchen.de > <mailto:xxxxxx@nieper-wisskirchen.de> > An: Takashi Kato <ktakashi19@gmail.com> <mailto:ktakashi19@gmail.com> > > > > Am 21.03.2017 um 08:52 schrieb Takashi Kato: > >> Then I need a bit more clarification. If the above case is allowed by this >> SRFI, then I think it implies one of the following 2 thing: >> >> - define-syntax, let-syntax or letrec-syntax may take sequence of <definition> >> followed by <transformer spec> >> e.g. >> (define-syntax foo (begin (define bar 0) (syntax-rules () ((_) bar)))) > This is what the spec currently says: > > " Whenever a keyword is bound to a macro transformer, and the macro > transformer is given by a transformer spec that is a macro use, the > keyword is bound to the macro transformer given by the transformer > spec that results from transcribing the macro use. It is an error if > the macro use does not expand into a transformer spec (but see below). > ... > > In order to facilitate writing sophisticated custom macro > transformers, it is allowed that a transformer spec expands into a > sequence of multiple definitions eventually followed by a > transformer spec (whose expansion may make use of the introduced > definitions)." > > What shall I clarify here? Where do you see any ambiguity? > > >> or >> >> - <macro use> inside of the <transformer spec> must specially be handled to >> detect any <definition> >> >> Either way, it's nice to be clarified by post finalization note. >> >> Cheers, >> >> _/_/ >> Takashi Kato >> >> >> On 20 March 2017 at 22:41, <xxxxxx@nieper-wisskirchen.de> <mailto:xxxxxx@nieper-wisskirchen.de> wrote: >>> Hi, >>> >>> thanks for asking this question. >>> >>> Am 08.03.2017 um 10:06 schrieb Takashi Kato: >>>> Hi, >>>> >>>> I believe the test case "Auxiliary definitions in custom macro >>>> transformers" is incorrect. The >>>> definition of the test is the following: >>>> >>>> (define-syntax my-macro-transformer >>>> (syntax-rules () >>>> ((my-macro-transformer) >>>> (begin (define foo 2) >>>> (syntax-rules () >>>> ((_) foo)))))) >>>> (letrec-syntax ((foo (my-macro-transformer))) >>>> (foo)) >>>> >>>> However this would be expanded to like this: >>>> >>>> (letrec-syntax ((foo (begin (define foo 2) >>>> (syntax-rules () >>>> ((_) foo))))) >>>> (foo)) >>> The spec allows that "in order to facilitate writing sophisticated >>> custom macro transformers" transformer specs expand into sequences of >>> multiple definitions eventually followed by a transformer spec (which is >>> the case in the example above). The scope of these definitions are in >>> the scope of the bindings of the letrec-syntax binding construct. >>> >>> The "foo" inside "(define foo 2)" and the foo in the syntax-rules >>> template are effectively being renamed due to hygiene. Thus, the whole >>> construct expands into "2". >>> >>> Was my explanation helpful? >>> >>> Best, >>> >>> Marc >>> > > To unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=MFwWpaugkEbDYbDRkSfFav2B2JgKp3gz > <http://www.simplelists.com/confirm.php?u=MFwWpaugkEbDYbDRkSfFav2B2JgKp3gz> > >
