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 05 Oct 2020 06:29 UTC 
Am Mo., 5. Okt. 2020 um 02:06 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

> On Fri, Oct 2, 2020 at 4:28 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

>> Was the Guile problem rooted in the condition system or rather in the
>> semantics of "with-exception-handler" and "raise"? As soon as I have
>> this working (as in every R7RS-small system), I can shim this
>> "with-exception-handler" to exchange native error objects with
>> conditions.
>
>
> I don't know the answer to that.  It may have been both.

For a definite answer, one of the Guile people may have to answer. For
R6RS/R7RS, the situation is much better than it was for Guile because
the low-level exception handling mechanism (raise, raise-continuable,
with-exception-handler, guard) is exactly the same. The implementation
just has to map whatever internal error objects it uses to the R6RS
condition types (possibly with a hidden field preserving the native
object in case the exception is not caught). It seems to me that the
biggest obstacle is not the R6RS condition system (apart from what
Will Clinger calls "mustard") but the ability to model a hierarchy of
condition types. When R7RS (large) becomes expressive enough, we
should check whether adopting R6RS/SRFI 35 is an option instead of
reinventing the wheel (and creating another potential layer of
incompatibility).

>> What does the phrase "to keep so. honest" exactly mean?

> To ensure that someone is consistent, that they say what they mean and mean what they say.

Thanks.

>> I am no R6RS expert,

> But you are very good at pointing out hidden inconsistencies.

Thanks again.

>> (*) One such corner case is when the right-hand sides of definitions
>> are expanded. In Unsyntax, I read the R7RS *very* liberally and chose
>> the R6RS model because I firmly believe that the intended reading of
>> the R7RS is flawed, more complicated to reason about, and does not to
>> take the existence of identifier syntax (which should behave like
>> variable references) into account.
>
>
> Can you explicate this last point further?

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. The R6RS expansion model was chosen
not to make the even?/odd? example working (which just demonstrates
the behavior) but after giving to what works best quite some thought.
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.

Now, identifier syntax should behave like any other variable
reference. But it cannot (in all corner cases) if variable references
are treated in a special way that does not match.

To illustrate my point further, think about how you would code an
expander for a <library body> (or any other <body>). In the R6RS
model, you go from top to bottom, expand each body form in the current
environment, dispatch on the type of the body form (variable
definition, syntax definition, etc.), extend the environment according
to the definition, and defer expansion of the non-expand-time
right-hand sides until you know the full body environment. In the R7RS
model as intended, you also go from top to bottom and you also have to
defer the expansion of the non-expand-time right-hand sides because
you need to know the full environment to determine the syntax in the
right-hand side. 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). Instead, you have to build your body environment anew
and expanding each right-hand side in each own body environment.
Moreover, when syntax objects appear on the right hand-sides, you have
to capture these intermediate environments, making it impossible to
use a non-pure data structure for body environments in general.

If you ask me, the intended R7RS (small) semantics was just a design
mistake (with good intentions, for sure, but it doesn't look as if WG
1 has given much thought to it, probably because it sounds plausible
at first glance). No implementation that also supports R6RS (Larceny
and Loko, for example) will support the R7RS model as written, and I
doubt that few pure R7RS implementations if any implement it fully and
correctly. In further revisions (and in amendments to R7RS), the clear
and easily implementable previous model should be adopted again. It
matters most to implementers and those hunting corner cases;
well-written real-world programs wouldn't notice the semantic changes.

Marc