Group Email Manager

login signup

Email list hosting service & mailing list manager

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)
Re: Invalid test case. Marc Nieper-Wißkirchen 24 Apr 2017 07:21 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>
>
>