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.htm l
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 thisThis is what the spec currently says:
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))))
" 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,The spec allows that "in order to facilitate writing sophisticated
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))
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
<http://www.simplelists.com/co
To unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=MFwWpaugkEbDYbDRkSf Fav2B2JgKp3gz nfirm.php?u=MFwWpaugkEbDYbDRkS >fFav2B2JgKp3gz