Group Email Manager

login signup
r6rs implementation? Felix Thibault (26 Sep 2020 15:28 UTC)
Re: r6rs implementation? Lassi Kortela (26 Sep 2020 15:41 UTC)
Re: r6rs implementation? Lassi Kortela (26 Sep 2020 15:44 UTC)
Re: r6rs implementation? Felix Thibault (26 Sep 2020 16:31 UTC)
Re: r6rs implementation? Marc Nieper-Wißkirchen (26 Sep 2020 17:12 UTC)
Re: r6rs implementation? Lassi Kortela (26 Sep 2020 18:21 UTC)
Re: r6rs implementation? Marc Nieper-Wißkirchen (26 Sep 2020 17:13 UTC)
Re: r6rs implementation? Lassi Kortela (26 Sep 2020 18:17 UTC)
Re: r6rs implementation? Marc Nieper-Wißkirchen (01 Oct 2020 13:57 UTC)
Re: r6rs implementation? John Cowan (01 Oct 2020 20:15 UTC)
Re: r6rs implementation? Marc Nieper-Wißkirchen (02 Oct 2020 05:19 UTC)
Re: r6rs implementation? John Cowan (02 Oct 2020 19:53 UTC)
Re: r6rs implementation? John Cowan (02 Oct 2020 20:00 UTC)
Sagittarius R6RS-R7RS paper Lassi Kortela (05 Oct 2020 06:36 UTC)
Re: Sagittarius R6RS-R7RS paper Marc Nieper-Wißkirchen (05 Oct 2020 07:31 UTC)
Re: r6rs implementation? Marc Nieper-Wißkirchen (02 Oct 2020 20:28 UTC)
Re: r6rs implementation? John Cowan (05 Oct 2020 00:06 UTC)
Re: r6rs implementation? Marc Nieper-Wißkirchen (05 Oct 2020 06:29 UTC)
Re: r6rs implementation? John Cowan (07 Oct 2020 02:40 UTC)
Re: r6rs implementation? Marc Nieper-Wißkirchen (07 Oct 2020 07:08 UTC)
Re: r6rs implementation? John Cowan (11 Oct 2020 03:56 UTC)
Re: r6rs implementation? Marc Nieper-Wißkirchen (11 Oct 2020 13:39 UTC)
Re: r6rs implementation? Felix Thibault (26 Sep 2020 21:21 UTC)
Re: r6rs implementation? Felix Thibault (26 Sep 2020 21:47 UTC)
Re: r6rs implementation? Marc Nieper-Wißkirchen 07 Oct 2020 07:07 UTC 
Am Mi., 7. Okt. 2020 um 04:40 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

> On Mon, Oct 5, 2020 at 2:29 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>> A variable reference (4.1.1) is just one type of syntax (one
>> expression type), which the expander initially has to treat like any
>> other expression type because the kind of an expression type doesn't
>> become apparent before expansion.

> Thanks, I understand now.  In the presence of identifier syntax, that is indeed true.  Without it, we always know the type of an identifier in operand position.

That is only superficially the case. For the compiler, there is not a
single type of variable reference. You may reference an imported
variable, a variable defined at top-level, a local variable defined in
an outer scope, a local variable earlier in this scope, or a local
variable that will be defined later in this scope. Depending on this,
the expander generally has to expand the variable reference into
different expansions. The problem already exists in R7RS (small); it
becomes only more apparent when you have identifier syntax. The right
way to think about it is that each variable reference *is* identifier
syntax. R7RS (small) just does not have a facility to define your own
type of identifier syntax.

>> In the intended R7RS (small) model, however, the semantics becomes
>> much more complicated because one type of syntax (variable references)
>> is now treated differently from all other types of syntax. For
>> variable references, later definitions are taken into account, for all
>> other types of syntax, they are not.
>
>
> More precisely, they need not be.  R7RS-small 5.4 says "Any use of a syntax keyword before its corresponding definition is an error. In particular, a use that precedes an inner definition will not apply an outer definition."  So it can signal an error or it can apply the inner definition.

If this means that the clear R6RS model is compatible with R7RS
(small), that's very good news.

To get everything right, let us consider the following example:

(let-syntax ((foo ...))
  (let* ()
    (define bar (lambda () (foo)))
    (define foo (lambda () ...))
    ...))

In the R6RS model, it's clear; the reference to `foo' in the first
inner definition is a variable reference, referencing the second inner
definition.

What about the R7RS model? I hope it is supposed to do the same.
(Otherwise, the meaning of the code would change if the order of the
two inner definitions is switched, making the idea that inner
definitions are equivalent to a letrec* questionable. Moreover,
reasoning in a lexical-local sense would become harder.)

>> However, finally, you cannot just expand the
>> right-hand sides in the resulting body environment (as it may contain
>> later syntax definitions that must not be applied by the intended R7RS
>> (small) model).
>
>
> Not "must not" but rather "are not required to be".

This will depend on the answer to the question raised in the
(let-syntax ((foo ...)) ...) example.

That said, we also have the library or program top-level. In R6RS,
their semantics are as in a <body>, which I also use in Unsyntax as
deferring the expansion of the right-hand sides is the only sensible
thing to do.

Consider:

(define-syntax macro
  (syntax-rules ()
    ((macro x)
     (begin
       (define x (lambda () y))
       ---)))))

(macro x)
(define y 'y)

When the macro is expanded, all occurrences of `y' are renamed because
of hygiene. So after one macro expansion we have:

(define x (lambda () y*))
---*
(define y 'y)

Now, if the right-hand sides were not deferred, the expander would
have to expand (lambda () y*) next. But what does it do with y*??? The
problem is that the meaning of this variable reference (remember, just
one kind of identifier syntax) depends on "---". If "---" in the macro
is "(define y 'macro-y)", y* won't reference the variable y defined
later because a definition for the renamed y* is available. Otherwise,
it would reference y.