pushed updated library tests Felix Thibault (21 Aug 2020 22:28 UTC)
Re: pushed updated library tests Marc Nieper-Wißkirchen (22 Aug 2020 15:27 UTC)
Re: pushed updated library tests Felix Thibault (22 Aug 2020 16:23 UTC)
Re: pushed updated library tests Marc Nieper-Wißkirchen (25 Aug 2020 07:04 UTC)
Re: pushed updated library tests Alex Shinn (25 Aug 2020 07:20 UTC)
Re: pushed updated library tests Marc Nieper-Wißkirchen (25 Aug 2020 07:40 UTC)
Re: pushed updated library tests Alex Shinn (25 Aug 2020 07:58 UTC)
Re: pushed updated library tests Marc Nieper-Wißkirchen (25 Aug 2020 08:13 UTC)
Re: pushed updated library tests Alex Shinn (27 Aug 2020 02:14 UTC)
Re: pushed updated library tests Marc Nieper-Wißkirchen (27 Aug 2020 07:35 UTC)
Re: pushed updated library tests John Cowan (27 Aug 2020 17:43 UTC)
Re: pushed updated library tests Felix Thibault (27 Aug 2020 22:19 UTC)
Re: pushed updated library tests Arthur A. Gleckler (27 Aug 2020 23:23 UTC)
Re: pushed updated library tests Alex Shinn (28 Aug 2020 00:43 UTC)
Re: pushed updated library tests Marc Nieper-Wißkirchen (28 Aug 2020 05:26 UTC)
Re: pushed updated library tests Alex Shinn (28 Aug 2020 05:35 UTC)
Re: pushed updated library tests Marc Nieper-Wißkirchen (28 Aug 2020 05:52 UTC)
Re: pushed updated library tests Marc Nieper-Wißkirchen (28 Aug 2020 13:47 UTC)
Re: pushed updated library tests Alex Shinn (28 Aug 2020 14:24 UTC)
Re: pushed updated library tests Marc Nieper-Wißkirchen (28 Aug 2020 15:03 UTC)
Re: pushed updated library tests Alex Shinn (31 Aug 2020 13:14 UTC)
Re: pushed updated library tests Marc Nieper-Wißkirchen (31 Aug 2020 14:44 UTC)
Re: pushed updated library tests Alex Shinn (31 Aug 2020 21:15 UTC)
Re: pushed updated library tests Marc Nieper-Wißkirchen (01 Sep 2020 06:52 UTC)
Re: pushed updated library tests Alex Shinn (01 Sep 2020 07:18 UTC)
Re: pushed updated library tests Marc Nieper-Wißkirchen (01 Sep 2020 07:24 UTC)
Re: pushed updated library tests Alex Shinn (01 Sep 2020 07:29 UTC)
Re: pushed updated library tests Marc Nieper-Wißkirchen (01 Sep 2020 07:47 UTC)
Re: pushed updated library tests Alex Shinn (02 Sep 2020 01:19 UTC)
Re: pushed updated library tests Marc Nieper-Wißkirchen (02 Sep 2020 07:02 UTC)
Re: pushed updated library tests Marc Nieper-Wißkirchen (31 Aug 2020 15:50 UTC)

Re: pushed updated library tests Marc Nieper-Wißkirchen 02 Sep 2020 07:02 UTC

Hi Alex,

> Apologies, your replies are very long and I've only had time to
> skim them, which is inconsiderate.  I'll have to bow out of this
> discussion (and all SRFI discussions) for a while now for personal
> reasons.

No problem. There are many more things more important than this
academic discussion. In particular, as we probably agree more than
that we disagree.

I hope your new job is going well. (May you want to tell me
(privately) where you are working now?)

> What I can say is the intent of the standard was not to allow
> arbitrary macro expansions into quoted cyclic data.  In fact,
> that is not a specification at all because it just translates to
> "implementation defined."  One can implement a quasiquote
> which supports cycles, but most don't.
>
> Quasiquote is somewhat special in that it is inherently a
> code-walking macro, something which should be discouraged
> but does come in handy on occasion.  Other examples include
> test/assert macros which report interesting variables referenced
> in their body, and variants of cut/chain which allow nesting
> <>/_ deeper in the body than just top-level.  The macro
> system itself and/or pattern matcher may want some limited
> walk ahead for diagnostics and/or optimization.  All of these
> run afoul of cycles.   In fact this is true whether they are
> quoted or otherwise, but a quote guarantees at least one
> extra safety depth and is easier to check against.

I agree with you that the macro expander cannot handle cyclic data and
that cyclic data and that the attempt to expand cyclic datums would be
an error. I think we also agree that at least after expansion, the
only place where cyclic datums are allowed are in expression of type
literal.

To make arbitrary code-walking by macros feasible, I think we also
agree that syntax-rules is not enough. The macro expander works
strictly top-to-bottom. For code-walking to be possible in all cases a
way to enforce expansion of a macro argument would be needed. While
cycles are the most obvious problem for code-walking macros, there are
a lot more (unknown macros in the body, unhygienic macros, include,
...).

> So you would either need to address this, or leave it all
> implementation defined.  What that means is it will work in
> some but not all implementations, which is actually the same
> specification as "is an error," so perhaps we've been arguing
> the same thing the whole time :)

I guess so. :) Every full implementation you would write or I would
write would probably report exactly the same programs as erroneous
(which includes a non-terminating macro expansion).

Moreover, if we just dropped the explicit restriction statement in
2.4, I guess nothing would change for both of us. No more programs
would be legal than that are now. In all cases that 2.4 forbids, the
expander would loop anyway.

Marc