A roadmap for R7RS Medium, if that’s a thing now

[Daphne Preston-Kendal]

So, it seems we have galvanized at least some of the group into a consensus about moving forward on ‘core language features’ rather than further portable libraries. And we even have a volunteer editor to produce a spec for an ‘R7RS Medium’. I see this as terrific progress. WG2’s charter instructs us to deliver intermediate specifications, so this is perfectly in keeping with that: at some point the intermediate specification for ‘R7RS Medium’ becomes one of the ‘work products’ we submit on a rolling basis.

John, I hope you’d be satisfied to turn things in this direction for a while?

I don’t propose for a moment throwing away the work that has been done on the Large (or I guess I should now say: LARGE) spec, but if a distinct Medium spec is to be delivered summarizing the core language on which R7RS Large libraries are to be based, I would suggest the following features as fitting more-or-less in the category of ‘core language features’:

From the Red Edition:
• (scheme ephemeron), weak references; to be extended by finalizers
• possibly (scheme comparator) as comparators a form a useful basis as a lingua franca for making data-structure operations type-generic, though they have been criticized

From the Tangerine Edition: perhaps SRFI 160?

From the Yellow Edition:
• syntax-case; to be extended by low-level syntax object destructuring procedures (; possibly to be defined in the spec in terms of Flatt's sets of scopes rather than Dybvig's marks and substitutions as in R6RS (the two models are semantically equivalent, but the former is simpler and more elegant imo)
• syntax parameters
• splicing-let{rec,}-syntax
• identifier-syntax
• identifier properties
• identifier aliasing

Additional syntax features:
• Auxiliary syntax keywords from SRFI 206

Misc additional features:
• Delimited continuations from SRFI 226
• Continuation marks from SRFI 226, with concomitant guarantees on the tail-position semantics of parameterize etc.
• A condition system (from R6RS? with restarts?)
• Record type inheritance (unifying SRFI 99 and R6RS?)
• Procedural record-type creation and reflection (ditto?)
• Some kind of guarantee on the performance of string-ref
• Require implementations to support form-feed as whitespace
• Procedure tags a la SRFI 229, though I would prefer a key-value mapping associated with procedures rather than just one slot, so that you can do multiple things with them
• Attempt to unify the R6RS and R7RS library systems, perhaps by supporting ‘library’ simply as a more concise alternative to ‘define-library’ when cond-expand and friends aren’t needed.

Perhaps more controversial:
• Keyword datums a la SRFI 88 (though on reflection I think Kawa and Racket got it right by making them non-expressions, which implies changing procedure call evaluation semantics somehow)
• Basic threading a la SRFI 18, maybe with atomic operations from SRFI 230. (Optional?)

Changes vs R7RS small: Review all ‘is an error’ and RFC 2119 ‘should’, ‘may’ instances etc. and decide when and how to tighten them up. I have a preliminary list of such cleanup cases, but it’s far from complete.

This is of course my entirely subjective perspective on what counts as the ‘core language’ needed to support the libraries of Large, and I write this in the expectation of at least some dissent ;-) but I hope we can direct those to, perhaps, a wiki page with a single plan of action. An agenda agreed at the start for what goes into this stage and what is delayed until the next stage.

All the Large libraries we’ve adopted so far remain part of Large, they just aren’t mentioned *yet* in the Medium specification; their SRFIs bzw R6RS chapters remain their official specs for now. (This means we won’t get editorially bogged down in specifying them and cleaning up their SRFI specs, distracting us from trying to get core language features settled.)

Considering how much of this consists of SRFIs written by Marc, I think he is a natural choice of editor ;-). I volunteer myself as co- or sub-editor if necessary.


Daphne

[Lassi Kortela]

Good stuff; things are moving in a very good direction.

The major change of approach I'd make is to go to Scheme implementers
early and often, asking them what they're willing to put up with.

> • Keyword datums a la SRFI 88 (though on reflection I think Kawa and Racket got it right by making them non-expressions, which implies changing procedure call evaluation semantics somehow)

We can specify a particular keyword read syntax without specifying
whether or not keywords are self-quoting. In R7RS you can type vectors
as #(1 2 3) but in R6RS you have to type '#(1 2 3).

I suggest we add keywords, but allow both non-self-quoting
implementations (Kawa and Racket) and self-quoting ones (everyone else).
This, together with procedural macros, should give a resonable
foundation for different implementations of keyword arguments while
enabling the surface syntax of keyword calls to be portable.

In Kawa you can do this:

> #:foo
/dev/tty:13:1: warning - keyword should be quoted if not in argument
position
foo:
> (define-syntax-case foo () ((foo a) #'(quote a)))
> (foo #:x)
x:

So a macro can implicitly quote a non-self-quoting keyword, if such a
thing is needed.

> • Basic threading a la SRFI 18, maybe with atomic operations from SRFI 230. (Optional?)

Would definitely talk to the implementers. What about Kawa and
IronScheme? I suspect it's too hard.

> Changes vs R7RS small: Review all ‘is an error’ and RFC 2119 ‘should’, ‘may’ instances etc. and decide when and how to tighten them up. I have a preliminary list of such cleanup cases, but it’s far from complete.

+1, great.

> what counts as the ‘core language’ needed to support the libraries of Large

Keyword arguments, or lack thereof, is the big question that affects
both the user-visible syntax of procedure calls and what's required of
Scheme implementations. Most other features are either standardized long
ago, or can be hidden under the covers of the implementation.

> Considering how much of this consists of SRFIs written by Marc, I think he is a natural choice of editor ;-). I volunteer myself as co- or sub-editor if necessary.

I strongly suggest starting from the R6RS spec and editing to suit. If
Mike Sperber has time to contribute, his advice would be a great help.

[Arthur A. Gleckler]

On Mon, Mar 7, 2022 at 1:16 PM Daphne Preston-Kendal <d...@nonceword.org> wrote:

 

John, I hope you’d be satisfied to turn things in this direction for a while?

I've been mostly quiet in this discussion, but I don't want my silence to be misinterpreted as assent, so I'm speaking up now.

I'm happy to stick with John's existing approach to R7RS Large.  I lurked on the R5RS mailing list, participated in one of the final IEEE Scheme standardization meetings in person, participated quite a bit in R6RS, was an editor of R7RS Small, and have been participating in R7RS Large.  Over and over, I've seen the perfect become the enemy of the good in Scheme standardization efforts, and I've seen how long that tendency has delayed the completion of those standards.  John's approach may not produce the diamond-like jewel that Schemers often want, but it is more likely to produce the practical, "batteries included" language that I'm eager to use.  In particular, the emphasis on libraries, including data structures, is a good idea.  Python, for example, has more users because of its vast collection of libraries than because of the language.  I certainly don't want Scheme to become ugly and inconsistent like core Python, but I don't see any danger of that in John's approach.

I'd be happy to participate in a "polishing" phase after the SRFIs are complete, or in parallel with the SRFI effort, but only with a strict time limit on it.  That kind of work can go on forever.

I'd love to see us recruit more of the authors and maintainers of big Scheme implementations to this discussion.  I'm trying to encourage the ones I know to join.

[Daphne Preston-Kendal]

FWIW I don’t see the two approaches as being in conflict. Indeed, we could possibly even productively work in parallel.


Daphne

> --
> You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/CALnw4L%2BnL2s6eimCFjRRA5yy68Zdv-EwSt-LPwOrhJp7TZtz0w%40mail.gmail.com.

[Martin Rodgers]

On 07/03/2022, Daphne Preston-Kendal <d...@nonceword.org> wrote:
> FWIW I don’t see the two approaches as being in conflict. Indeed, we could
> possibly even productively work in parallel.

Agreed. I see no conflict at all. I'm confused by the suggestion that
there might be one! This is exactly what I mean when I say this isn't
a zero-sum game. I'm assuming that everyone here knows what that is,
but just in case anyone here *doesn't* know, the link below is for
them.

https://en.wikipedia.org/wiki/Zero-sum_game

[Arthur A. Gleckler]

On Mon, Mar 7, 2022 at 1:54 PM Martin Rodgers <mcro...@gmail.com> wrote:

 

Agreed. I see no conflict at all. I'm confused by the suggestion that
there might be one! This is exactly what I mean when I say this isn't
a zero-sum game. I'm assuming that everyone here knows what that is,
but just in case anyone here *doesn't* know, the link below is for
them. 

Lassi has been saying that making libraries part of R7RS Large is a bad idea, and that all the libraries added are likely to be abandoned by future standardizers. 

[Lassi Kortela]

> Lassi has been saying that making libraries part of R7RS Large is a bad
> idea, and that all the libraries added are likely to be abandoned by
> future standardizers.

If people insist on having the libraries in RnRS, the next best thing is
to split the core language work onto a separate track. That seems to be
a natural point of convergence that sufficiently satisfies everybody.

However, the core language effort is still likely to fail without
proactive and continual diplomacy toward implementers. For that, you
need one leader, and now you're back to democracy being a problem.

So you should decide who leads the core language effort. If you keep the
core and library efforts both under the banner of WG2, it will look
weird if you have a leader for core but democracy for libs. People will
be confused about where the lines are drawn.

[Dr. Arne Babenhauserheide]

Daphne Preston-Kendal <d...@nonceword.org> writes:

> I don’t propose for a moment throwing away the work that has been done
> on the Large (or I guess I should now say: LARGE) spec, but if a
> distinct Medium spec is to be delivered summarizing the core language
> on which R7RS Large libraries are to be based, I would suggest the

One practical path that could help to stay on direct advantages for
portability could be to look at the Preludes and Postludes¹ in the
r7rs-benchmarks² and ask which features added to r7rs-small could allow
using the code of the tests without any changes.

This is on a small scale and would not yet provide compatibility for
very complex libraries, but simply gaining the ability to drop in some
algorithm without any changes would make it much easier to take a bet on
portability: “I see that library X exists written in R7RS Scheme, I’m
sure I can use it to build my tool”.

¹: https://github.com/ecraven/r7rs-benchmarks/tree/master/src
²: https://ecraven.github.io/r7rs-benchmarks/

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[Martin Rodgers]

Well, I can understand that. For a long time I felt R7RS only needed
the Small dialect plus a standard way to import SRFIs. Yet the issue
of mapping SRFI names into library names apparently remains unresolved
for some members of WG2. I hope this has now been resolved or will be
soon.

At the same time, we have both Chibi and Larceny providing the entire
Red and Tangerine Editions. I think this is a very good thing. It
gives us something concrete with whch evaluate R7RS Large so far. Even
if it has too much of "rough consensus and running code" for some of
us, others appreciate the value of running code. (I've surely said
enough about *my* position on this.)

So until recently I felt like we were approaching a consensus on where
R7 Large was headed. My understanding is that this is what "John's
approach" refers to - that we do actually have some significant degree
of consensus? If so, I will happily add my support to that. (I've
surely said enough about *my* position on this.)

[Martin Rodgers]

Is R7RS Small not enough to write a benchmarking tool? I was able to
write a small benchmarking library using only R7RS Small. I've so far
used it to test 38 of the Gabriel benchmarks on Chibi and Larceny
without change.

The only "prelude" I needed was for an R7RS program body:

(import
(benchmarking)
(scheme base))

Alternately, a small wrapper for the real benchmark:

(import
(only (scheme base) error unless include)
(scheme r5rs)
(benchmarking))

(include "nboyer.sch")

(nboyer-benchmark 4)

The benchmarking library looks like this:

(define-library (benchmarking)
(export
default-test
print
run-benchmark)
(import
(benchmarking time) ; see below
(scheme case-lambda)
(scheme write)
(scheme base))
(begin
(define (print x)
(display x)
(newline))

(define (default-test x)
(print x)
#t)

(define run-benchmark
(case-lambda
((name thunk)
(run-benchmark name thunk 1))
((name thunk count)
(run-benchmark name 1 thunk (lambda (x) #t)))
((name count thunk ok?)
(display
"--------------------------------------------------------")
(newline)
(display name)
(display ", ")
(display count)
(display " iterations.")
(newline)
(time (let loop ((n (- count 1))
(result (thunk)))
(unless (ok? result)
(error "Error: Benchmark program
returned wrong result: " result))
(when (positive? n)
(loop (- n 1) (thunk))))))))))

(define-library (benchmarking time)
(export
time)
(import
(scheme time)
(scheme write)
(scheme base))
(begin
(define-syntax time
(syntax-rules ()
((_ e)
(let* ((start (current-jiffy))
(result (call-with-values (lambda () e) list))
(end (current-jiffy))
(dur (/ (- end start) (jiffies-per-second)))
(minutes (floor (/ dur 60)))
(seconds (- dur (* 60 minutes))))
(display (exact minutes))
(display " mins, ")
(display (inexact seconds))
(display " seconds. ")
(display (inexact dur))
(display " total.")
(newline)
(apply values result)))))))

[Per Bothner]

On 3/7/22 13:37, Lassi Kortela wrote:
>> • Basic threading a la SRFI 18, maybe with atomic operations from SRFI 230. (Optional?)
>
> Would definitely talk to the implementers. What about Kawa and IronScheme? I suspect it's too hard.

Most of the thread-xxx procedures can probably be implemented in Kawa on top on Java threads.
One problem I noticed is thread-terminate!. Kawa already has 'futures', implemented as a
thin layer on top of primitive Java threads. Haven't looked at mutex, condition variables,
or atomic operations, but my guess is they wouldn't be too hard.

Mixing continuations and threads is a different matter.

--
--Per Bothner
p...@bothner.com http://per.bothner.com/

[Dr. Arne Babenhauserheide]

Lassi Kortela <la...@lassi.io> writes:

>> Lassi has been saying that making libraries part of R7RS Large is a
>> bad idea, and that all the libraries added are likely to be
>> abandoned by future standardizers.
>
> If people insist on having the libraries in RnRS, the next best thing
> is to split the core language work onto a separate track. That seems
> to be a natural point of convergence that sufficiently satisfies
> everybody.
>
> However, the core language effort is still likely to fail without
> proactive and continual diplomacy toward implementers. For that, you
> need one leader, and now you're back to democracy being a problem.

Please slow down. You’re mixing up things.

In Guile there is now awareness of the idea of r7rs-medium. Not because
some leader approached the leader of Guile, but because I posted our
thread in the IRC channel.

We don’t need a dictator for proactive diplomacy. We need communication.
Keeping in touch. Pinging the people needed for a given topic.

That works better with a group in which and through which knowledge is
distributed and information is gathered than with a leader as
bottleneck. It works well with democracy, because that involves more
people who can spread and gather relevant information.

[Dr. Arne Babenhauserheide]

Martin Rodgers <mcro...@gmail.com> writes:

> On 07/03/2022, Dr. Arne Babenhauserheide <arne...@web.de> wrote:
>> ¹: https://github.com/ecraven/r7rs-benchmarks/tree/master/src
>> ²: https://ecraven.github.io/r7rs-benchmarks/
>
> Is R7RS Small not enough to write a benchmarking tool?

My point isn’t the benchmarking tool, but the benchmarks.

Some of those need preludes to work on the different Schemes.

They are a collection of small snippets of code that should work
everywhere, but require preludes for some of the 18 Schemes that have
serious coverage.

Checking what’s added there and whether this is something that might be
a good fit for R7RS-medium could be a good first step. It points into
the direction of practical pain points.

[Marc Nieper-Wißkirchen]

Thanks for starting this thread, Daphne.

Let us pause for a moment, though, before we move forward. Already
everyone is writing down what they would like to see in "R7RS Medium"
(which is quite understandable, of course), but there has to be some
agreement on the bigger picture first. What gets into R7RS Medium and
whatnot, and, if, how should then follow mostly naturally from the
bigger picture and not necessarily from individual wishes. Depending
on what the direction for "R7RS Medium" is going to be, I may or I may
not be a good candidate for an editor. But that's the second step and
can be decided then. I would volunteer for coordinating drawing the
bigger picture as a first step.

In any case, such a venture would be quite an amount of work. Although
there can never be a guarantee that the resulting product will
eventually be gratefully received by the Scheme community, it would be
good to assure some endorsement beforehand:

- John is in charge of the R7RS-large process. If "R7RS Medium" is to
become a product that can serve as a viable, underlying vehicle for
R7RS-large, hearing his opinion on this swing of things is important.
- If the idea of "R7RS Medium" is to be more than just a platform for
the larger language but also a usable language in itself to be
published separately from R7RS-small and R7RS-large, we have to
approach the SC. The same is true when we want to have a better name;
this is, in particular, an important question if we want "R7RS Medium"
to serve as the successor of R6RS as well.
- Related to both items above is the question of whether we want to
allow ourselves to drop strict (!) R7RS-small compatibility.

One may want to postpone approaching the SC until the bigger picture
stands. I would also advise against trying to get all implementers on
board at this stage. We need the bigger picture first. If we wanted
maximal implementer's support, we would recreate R7RS-small under a
different name.

Marc

Am Mo., 7. März 2022 um 22:16 Uhr schrieb Daphne Preston-Kendal
<d...@nonceword.org>:

> --
> You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/21BBE3FB-7469-43FF-8246-2B72F0B0B1E6%40nonceword.org.

[Lassi Kortela]

> Please slow down. You’re mixing up things.
>
> In Guile there is now awareness of the idea of r7rs-medium. Not because
> some leader approached the leader of Guile, but because I posted our
> thread in the IRC channel.
>
> We don’t need a dictator for proactive diplomacy. We need communication.
> Keeping in touch. Pinging the people needed for a given topic.
>
> That works better with a group in which and through which knowledge is
> distributed and information is gathered than with a leader as
> bottleneck. It works well with democracy, because that involves more
> people who can spread and gather relevant information.

We may not disagree as much as it seems. You used the word "moderator"
in an earlier mail, explaining a role quite similar to what I envision.

A leader doesn't have to be the sole point of contact, and definitely
shouldn't do everything himself (and doesn't have to be the same person
for the entire duration of the project - the role can rotate among
several people). I'm just skeptical that a committee can keep things
cohesive. The cohesion problem grows more difficult as you add more
implementers. They disagree about a great deal. I expect that it's hard
to keep the implementers from stepping on each other's toes if you don't
have one person as the tie breaker and schedule wrangler who says "the
discussion has gone on long enough, this is what we'll do."

Some people are primed to see having one leader as dictatorial, but if
he does a bad job the followers will leave. I feel more comfortable when
a complex project has one leader, even if I disagree with him at times.

[Daphne Preston-Kendal]

On 8 Mar 2022, at 08:55, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

> Depending
> on what the direction for "R7RS Medium" is going to be, I may or I may
> not be a good candidate for an editor. But that's the second step and
> can be decided then. I would volunteer for coordinating drawing the
> bigger picture as a first step.
>
> In any case, such a venture would be quite an amount of work.

Assuming we can reuse R7RS small, R6RS, and SRFI spec language for a Medium spec, the difficulties are:
(a) deciding what features go in (my list is intended as a list of candidates to define the boundaries of such deliberations, rather than as a wishlist/vote in favour of everything mentioned)
(b) deciding which version of a feature/spec to prioritize, where multiple possibilities exist (though usually it’s a question of R6RS vs a SRFI, or R7RS vs R6RS; I don’t expect any three-way choices)
(c) organizing and editing the text, largely copied from those specs, into a single coherent document

There is also
(d) designing and writing new specs for features which are not in any of them, or when work needs to be done to unify different approaches rather than choosing between them (as in R7 vs R6 define-record-type, define-library vs library (including phasing and, sigh, versioning))
but, at least from my very preliminary draft agenda of features of consider, we already have specs for most of the things we would probably wish to put in.

It’s certainly not a small amount of work, but — as you remarked — much more manageable than the whole R7RS Large project. I would tentatively, and conservatively, estimate that we could be done in 18 months to 2 years.

And if another group wishes to work in parallel to continue defining useful data structures, macros, etc. as portable libraries — so much the better. (I do not share Lassi’s view that such libraries are too difficult to design, nor do I think future implementers or committees will simply ignore them.)

> Although
> there can never be a guarantee that the resulting product will
> eventually be gratefully received by the Scheme community, it would be
> good to assure some endorsement beforehand:
>
> - John is in charge of the R7RS-large process. If "R7RS Medium" is to
> become a product that can serve as a viable, underlying vehicle for
> R7RS-large, hearing his opinion on this swing of things is important.

Agreed.

> - If the idea of "R7RS Medium" is to be more than just a platform for
> the larger language but also a usable language in itself to be
> published separately from R7RS-small and R7RS-large, we have to
> approach the SC. The same is true when we want to have a better name;
> this is, in particular, an important question if we want "R7RS Medium"
> to serve as the successor of R6RS as well.

Honestly, I don’t think anyone will support, or will have any reason to support, R7RS Medium without also supporting R7RS Large. R7RS Large will consist *almost* entirely of portable libraries on top of R7RS Medium — with ready-to-go sample implementations any implementation can just drop in. (The exceptions to portability are things that add additional system interfaces, like sockets or whatever. But I don’t see any reason for implementations not to adopt those too, in most cases.)

This is why I considered Medium an intermediate artefact on the way to Large, and why I (still) feel that no WG2 charter revision is necessary.

> - Related to both items above is the question of whether we want to
> allow ourselves to drop strict (!) R7RS-small compatibility.

My instinct is ‘no, R7RS small compatibility is a must’, though I realize that there are unfortunate edge cases: e.g. if we adopted continuation marks, this — strictly (!) — would mean keeping the redundant delay-force and the troublesome requirement on the dynamic environment of force calls. My reaction to that case, at least, is ‘oh well’ (or ‘well, we could introduce an alternative “force”, perhaps called “resolve” or something, which behaves properly in this regard’).

I suspect we can come up with similar workarounds in other cases, but also that such cases will be very limited in number: R7RS small is a very flexible basis to work with, to WG1’s credit.

> One may want to postpone approaching the SC until the bigger picture
> stands. I would also advise against trying to get all implementers on
> board at this stage. We need the bigger picture first. If we wanted
> maximal implementer's support, we would recreate R7RS-small under a
> different name.

Talking to implementers now can’t hurt, though. It’s good to hear that Guile is aware of this effort, and I already appreciate Per’s input greatly.

> Marc

Daphne

[Marc Nieper-Wißkirchen]

Am Di., 8. März 2022 um 09:37 Uhr schrieb Daphne Preston-Kendal
<d...@nonceword.org>:
>

> On 8 Mar 2022, at 08:55, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:
>
> > Depending
> > on what the direction for "R7RS Medium" is going to be, I may or I may
> > not be a good candidate for an editor. But that's the second step and
> > can be decided then. I would volunteer for coordinating drawing the
> > bigger picture as a first step.
> >
> > In any case, such a venture would be quite an amount of work.
>
> Assuming we can reuse R7RS small, R6RS, and SRFI spec language for a Medium spec, the difficulties are:
> (a) deciding what features go in (my list is intended as a list of candidates to define the boundaries of such deliberations, rather than as a wishlist/vote in favour of everything mentioned)
> (b) deciding which version of a feature/spec to prioritize, where multiple possibilities exist (though usually it’s a question of R6RS vs a SRFI, or R7RS vs R6RS; I don’t expect any three-way choices)
> (c) organizing and editing the text, largely copied from those specs, into a single coherent document
>
> There is also
> (d) designing and writing new specs for features which are not in any of them, or when work needs to be done to unify different approaches rather than choosing between them (as in R7 vs R6 define-record-type, define-library vs library (including phasing and, sigh, versioning))
> but, at least from my very preliminary draft agenda of features of consider, we already have specs for most of the things we would probably wish to put in.

Part of drawing the bigger picture is also whether we want "R7RS
Medium" to be home also for the R6RS camp.

A likewise fundamental question is how demanding "R7RS Medium" will be
for implementers. The stricter the standard, the more guarantees the
programmer has and the easier it is to write portable programs, but
then more work has to be done by implementers as the resulting
language will probably diverge from the respective native dialect.

[...]

> > - If the idea of "R7RS Medium" is to be more than just a platform for
> > the larger language but also a usable language in itself to be
> > published separately from R7RS-small and R7RS-large, we have to
> > approach the SC. The same is true when we want to have a better name;
> > this is, in particular, an important question if we want "R7RS Medium"
> > to serve as the successor of R6RS as well.
>
> Honestly, I don’t think anyone will support, or will have any reason to support, R7RS Medium without also supporting R7RS Large. R7RS Large will consist *almost* entirely of portable libraries on top of R7RS Medium — with ready-to-go sample implementations any implementation can just drop in. (The exceptions to portability are things that add additional system interfaces, like sockets or whatever. But I don’t see any reason for implementations not to adopt those too, in most cases.)

Some folk including implementers will support R7RS-large (when it is
no effort to do so as you write), but won't endorse it. But they may
endorse "R7RS Medium". I think we have an example for this with
respect to R7RS and the SRFI process. While Chez (or, rather, the
driving forces behind it) are not against supporting R7RS where easily
possible, they don't seem to endorse it in a way that would mean
making compromises in favor of it. Nor are SRFIs given any special
status from my reading of the issue tracker. So I think it can become
very important to deliver a standalone product; but it's important
that this standalone product will sit between existing (and future)
standards so that there won't be another split.

> This is why I considered Medium an intermediate artefact on the way to Large, and why I (still) feel that no WG2 charter revision is necessary.
>
> > - Related to both items above is the question of whether we want to
> > allow ourselves to drop strict (!) R7RS-small compatibility.
>
> My instinct is ‘no, R7RS small compatibility is a must’, though I realize that there are unfortunate edge cases: e.g. if we adopted continuation marks, this — strictly (!) — would mean keeping the redundant delay-force and the troublesome requirement on the dynamic environment of force calls. My reaction to that case, at least, is ‘oh well’ (or ‘well, we could introduce an alternative “force”, perhaps called “resolve” or something, which behaves properly in this regard’).
>
> I suspect we can come up with similar workarounds in other cases, but also that such cases will be very limited in number: R7RS small is a very flexible basis to work with, to WG1’s credit.

The number of cases is probably small. And won't affect real-world
programs greatly. Maintaining strict compatibility just to follow the
law would be a bad thing if the resulting language is worse than
without.

But there's actually one point where R7RS-small's semantics will have
to be modified non-trivially: R7RS-small allows redefinitions at the
top-level of programs. But that does not go well with the R6RS
expansion semantics that is needed to make, for example, identifier
macros work properly. (This is not specific to "R7RS Medium"; such a
change is already needed for the current R7RS-large.)

I haven't checked the whole R7RS-small document yet whether some other
hidden problem lurks there.

In any case, when the R7RS project was born, it was said that both the
small and the large language would be developed in parallel. In such a
model, strict compatibility would have been easy to achieve. Now for
reasons that are irrelevant here, we see the development of the large
language long after the small language was done. It's quite natural to
expect that some points of the already 9-year old R7RS-small may have
to be revised. Even a relatively conservative language like C++
deprecates and removes features on such a time scale. One could also
use this process to clean up R7RS-small where it is not well-defined
(e.g. the expression-level cond-expand).

> > One may want to postpone approaching the SC until the bigger picture
> > stands. I would also advise against trying to get all implementers on
> > board at this stage. We need the bigger picture first. If we wanted
> > maximal implementer's support, we would recreate R7RS-small under a
> > different name.
>
> Talking to implementers now can’t hurt, though. It’s good to hear that Guile is aware of this effort, and I already appreciate Per’s input greatly.

For sure! I just wanted to say that taking the intersection of all
native dialects would lead to R7RS-small, which achieves this maximal
compatibility already greatly.

Marc

[Dr. Arne Babenhauserheide]

Lassi Kortela <la...@lassi.io> writes:

> if you don't have one person as the tie breaker and schedule wrangler
> who says "the discussion has gone on long enough, this is what we'll
> do."

In democracy what the responsible person says is „the discussion has
gone on very long, time to put it to a vote?“

Or more open: „This is what I would propose — do you have essential
additional input or can we put it to the vote so we can move forward?“.

Democracy often means convincing people and using the vote to resolve
blocks.

> Some people are primed to see having one leader as dictatorial, but if
> he does a bad job the followers will leave.

This can occur far too late because people develop loyalty, and if they
leave too late, it’s with a sour feeling.

> I feel more comfortable when a complex project has one leader, even if
> I disagree with him at times.

I also feel more comfortable if there’s one responsible person to tie it
all together. But that does not mean forgoing democratic decision
making. It just means to do it in an organized fashion with good
consolidation of information.

[Daphne Preston-Kendal]

On 8 Mar 2022, at 10:17, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

> Part of drawing the bigger picture is also whether we want "R7RS
> Medium" to be home also for the R6RS camp.
>
> A likewise fundamental question is how demanding "R7RS Medium" will be
> for implementers. The stricter the standard, the more guarantees the
> programmer has and the easier it is to write portable programs, but
> then more work has to be done by implementers as the resulting
> language will probably diverge from the respective native dialect.

These two questions may be related. I hope the R6RS people will be enthusiastic enough about getting delimited continuations, syntax parameters, etc. to support the effort, especially if we try to support their code (by e.g. some support for R6RS library declarations and record-type definitions).

On the other hand, we have a ‘language strangeness budget’ from the implementer’s perspective as well as the user’s.
<https://steveklabnik.com/writing/the-language-strangeness-budget>
R7RS small spent its budget very conservatively and won large support from implementers because of it.

If we spend less of our language strangeness budget on the strict error-checking requirements R6RS imposed and instead spend it on delimited continuations and continuation marks, that would perhaps be reasonable (although the two sides of the trade-off don’t quite look balanced to me). To answer these questions at all, we do need input from the R6RS community and from implementers.

>> I suspect we can come up with similar workarounds in other cases, but also that such cases will be very limited in number: R7RS small is a very flexible basis to work with, to WG1’s credit.
>
> The number of cases is probably small. And won't affect real-world
> programs greatly. Maintaining strict compatibility just to follow the
> law would be a bad thing if the resulting language is worse than
> without.
>
> But there's actually one point where R7RS-small's semantics will have
> to be modified non-trivially: R7RS-small allows redefinitions at the
> top-level of programs. But that does not go well with the R6RS
> expansion semantics that is needed to make, for example, identifier
> macros work properly. (This is not specific to "R7RS Medium"; such a
> change is already needed for the current R7RS-large.)

I think R7RS small’s requirement here is quite reasonable. Redefinitions are only allowed in the REPL, not in libraries or top-level programs, and only have to have retroactive effect for procedures, not syntactic keywords. (Though even Chibi breaks this by inlining some procedures (‘opcodes’) like ‘cons’, ‘car’, ‘cdr’ etc. in its bytecode.)

(R7RS small makes a clean distinction between running a top-level program, which has basically library-like semantics, and the ability to run a program as if its entire code were pasted into a REPL, which is not guaranteed to be supported.)

I realize this is less ideal when syntactic keywords are meant to look like variables as in the case of identifier-syntax, but I think it’s an acceptable compromise. We could make it less painful by adopting something like eval-when so that, e.g., identifier syntax used as a compiler macro can choose to only expand like a macro in compiled code, and otherwise just become a regular procedure call when at the REPL. (Oops, there goes my featureitis again. And eval-when is badly designed in Common Lisp, so maybe another approach.)

> I haven't checked the whole R7RS-small document yet whether some other
> hidden problem lurks there.
>
> In any case, when the R7RS project was born, it was said that both the
> small and the large language would be developed in parallel. In such a
> model, strict compatibility would have been easy to achieve. Now for
> reasons that are irrelevant here, we see the development of the large
> language long after the small language was done. It's quite natural to
> expect that some points of the already 9-year old R7RS-small may have
> to be revised. Even a relatively conservative language like C++
> deprecates and removes features on such a time scale. One could also
> use this process to clean up R7RS-small where it is not well-defined
> (e.g. the expression-level cond-expand).

I think my impression is that we will have to see what issues arise when we actually try to write Medium.


Daphne

[Marc Nieper-Wißkirchen]

Am Di., 8. März 2022 um 11:02 Uhr schrieb Daphne Preston-Kendal
<d...@nonceword.org>:
>

> On 8 Mar 2022, at 10:17, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:
>
> > Part of drawing the bigger picture is also whether we want "R7RS
> > Medium" to be home also for the R6RS camp.
> >
> > A likewise fundamental question is how demanding "R7RS Medium" will be
> > for implementers. The stricter the standard, the more guarantees the
> > programmer has and the easier it is to write portable programs, but
> > then more work has to be done by implementers as the resulting
> > language will probably diverge from the respective native dialect.
>
> These two questions may be related. I hope the R6RS people will be enthusiastic enough about getting delimited continuations, syntax parameters, etc. to support the effort, especially if we try to support their code (by e.g. some support for R6RS library declarations and record-type definitions).
>
> On the other hand, we have a ‘language strangeness budget’ from the implementer’s perspective as well as the user’s.
> <https://steveklabnik.com/writing/the-language-strangeness-budget>
> R7RS small spent its budget very conservatively and won large support from implementers because of it.
>
> If we spend less of our language strangeness budget on the strict error-checking requirements R6RS imposed and instead spend it on delimited continuations and continuation marks, that would perhaps be reasonable (although the two sides of the trade-off don’t quite look balanced to me). To answer these questions at all, we do need input from the R6RS community and from implementers.

I would also say that these two sides are not quite balanced; adding
strict error-checking requires some effort but doesn't really
interfere with the language core. If anything, it forces implementers
to write their code more carefully, which is a good thing IMO.

>
> >> I suspect we can come up with similar workarounds in other cases, but also that such cases will be very limited in number: R7RS small is a very flexible basis to work with, to WG1’s credit.
> >
> > The number of cases is probably small. And won't affect real-world
> > programs greatly. Maintaining strict compatibility just to follow the
> > law would be a bad thing if the resulting language is worse than
> > without.
> >
> > But there's actually one point where R7RS-small's semantics will have
> > to be modified non-trivially: R7RS-small allows redefinitions at the
> > top-level of programs. But that does not go well with the R6RS
> > expansion semantics that is needed to make, for example, identifier
> > macros work properly. (This is not specific to "R7RS Medium"; such a
> > change is already needed for the current R7RS-large.)
>
> I think R7RS small’s requirement here is quite reasonable. Redefinitions are only allowed in the REPL, not in libraries or top-level programs, and only have to have retroactive effect for procedures, not syntactic keywords. (Though even Chibi breaks this by inlining some procedures (‘opcodes’) like ‘cons’, ‘car’, ‘cdr’ etc. in its bytecode.)
>
> (R7RS small makes a clean distinction between running a top-level program, which has basically library-like semantics, and the ability to run a program as if its entire code were pasted into a REPL, which is not guaranteed to be supported.)

By 5.3.1 of the R7RS-small, redefinitions are allowed at the program
top-level, voiding your argument.

> I realize this is less ideal when syntactic keywords are meant to look like variables as in the case of identifier-syntax, but I think it’s an acceptable compromise. We could make it less painful by adopting something like eval-when so that, e.g., identifier syntax used as a compiler macro can choose to only expand like a macro in compiled code, and otherwise just become a regular procedure call when at the REPL. (Oops, there goes my featureitis again. And eval-when is badly designed in Common Lisp, so maybe another approach.)

Please don't introduce any distinction between interpreted and
compiled code in the language; that should be an implementation
detail.

> > I haven't checked the whole R7RS-small document yet whether some other
> > hidden problem lurks there.
> >
> > In any case, when the R7RS project was born, it was said that both the
> > small and the large language would be developed in parallel. In such a
> > model, strict compatibility would have been easy to achieve. Now for
> > reasons that are irrelevant here, we see the development of the large
> > language long after the small language was done. It's quite natural to
> > expect that some points of the already 9-year old R7RS-small may have
> > to be revised. Even a relatively conservative language like C++
> > deprecates and removes features on such a time scale. One could also
> > use this process to clean up R7RS-small where it is not well-defined
> > (e.g. the expression-level cond-expand).
>
> I think my impression is that we will have to see what issues arise when we actually try to write Medium.

Yes; adding new features to R7RS-small and reconciliation with R6RS
will both exhibit such issues. We just need to know beforehand whether
we are allowed to waive strict R7RS-small compatibility where it is
reasonable to do so.

[Daphne Preston-Kendal]

On 8 Mar 2022, at 11:21, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

>> I think R7RS small’s requirement here is quite reasonable. Redefinitions are only allowed in the REPL, not in libraries or top-level programs, and only have to have retroactive effect for procedures, not syntactic keywords. (Though even Chibi breaks this by inlining some procedures (‘opcodes’) like ‘cons’, ‘car’, ‘cdr’ etc. in its bytecode.)
>>
>> (R7RS small makes a clean distinction between running a top-level program, which has basically library-like semantics, and the ability to run a program as if its entire code were pasted into a REPL, which is not guaranteed to be supported.)
>
> By 5.3.1 of the R7RS-small, redefinitions are allowed at the program
> top-level, voiding your argument.

Ah, I was looking at the last paragraph of section 5.2 — but that applies only to imported bindings. Hmm.

>> I realize this is less ideal when syntactic keywords are meant to look like variables as in the case of identifier-syntax, but I think it’s an acceptable compromise. We could make it less painful by adopting something like eval-when so that, e.g., identifier syntax used as a compiler macro can choose to only expand like a macro in compiled code, and otherwise just become a regular procedure call when at the REPL. (Oops, there goes my featureitis again. And eval-when is badly designed in Common Lisp, so maybe another approach.)
>
> Please don't introduce any distinction between interpreted and
> compiled code in the language; that should be an implementation
> detail.

A cond-expand feature, then?

(define-syntax define-compiler-macro
(syntax-rules ()
((_ name proc stx-transformer)
(cond-expand
(interactive
(define name proc))
(else
(begin
(define compiler-macro-proc proc)
(define stx-transformer-proc stx-transformer)
(define-syntax name
(lambda (stx)
(if (identifier? stx)
#'compiler-macro-proc
(stx-transformer-proc stx))))))))))

(define-compiler-macro foo
(lambda (x) (list 'procedure-call x))
(syntax-rules () ((_ x) `(syntax-expansion ,x))))

(foo 4) ;=> (procedure-call 4) at the REPL, (syntax-expansion 4) in a library
(let ((bar foo)) (bar 4)) ;=> (procedure-call 4) everywhere

Daphne

[Lassi Kortela]

>> Some people are primed to see having one leader as dictatorial, but if
>> he does a bad job the followers will leave.

> This can occur far too late because people develop loyalty, and if they
> leave too late, it’s with a sour feeling.

Democracy can produce exactly the same result, as it currently has in WG2.

> I also feel more comfortable if there’s one responsible person to tie it
> all together. But that does not mean forgoing democratic decision
> making.

OK, we disagree there. My experience is that in many situations there's
a small minority of people who know what to do, and convincing the rest
in a timely manner is often impossible.

[Marc Nieper-Wißkirchen]

Am Di., 8. März 2022 um 11:43 Uhr schrieb Daphne Preston-Kendal
<d...@nonceword.org>:
>

You can certainly add such a cond-expand flag, but it would be bad
language design if every macro writer has to be aware of this flag.
Also, without modifying the top-level program semantics of R7RS-small,
the program top-level would have to count as interactive, which is at
least questionable.

As there is no real use of redefinitions in top-level programs (and
could even be considered bad style), the answer to the question of
whether removing that feature or whether piling a wholly new feature
that complicates the language semantics on top is simple in my
opinion.

Besides, your solution is not a universal one; it wouldn't work with
my example from [1] (when even and odd are actually taking keyword
arguments realized with macro-technology).

Anyway, the interactive level shouldn't affect the language design
much; these questions should be considered when the static language is
done. Even R7RS-small says only very few things about the REPL. As
much as any Scheme standard should support a debugger, it should
support a REPL. But as with debuggers that doesn't mean that it makes
sense to standardize everything in that department, quite the
contrary.

--

[1] https://groups.google.com/g/scheme-reports-wg2/c/cp7Jh8lv2Dg

[Martin Rodgers]

On 08/03/2022, Dr. Arne Babenhauserheide <arne...@web.de> wrote:
>
> Martin Rodgers <mcro...@gmail.com> writes:
>
>> On 07/03/2022, Dr. Arne Babenhauserheide <arne...@web.de> wrote:
>>> ¹: https://github.com/ecraven/r7rs-benchmarks/tree/master/src
>>> ²: https://ecraven.github.io/r7rs-benchmarks/
>>
>> Is R7RS Small not enough to write a benchmarking tool?
>
> My point isn’t the benchmarking tool, but the benchmarks.
>
> Some of those need preludes to work on the different Schemes.

Note: I address Medium below, but first I'd like to say a few things
about preludes. I'll use quotes because I don't believe we need
anything as crude as a prelude when we use R7RS. I also talk about
SRFI 138.

Yes, for the imports. That's why I use a wrapper program that includes
the benchmark. The R7 "prelude" you refer to can be just for the
imports, or it can be a wrapper program. It's trivial. No new
libraries are needed.

E.g. for the fft benchmarch, Larceny 1.3 requires (srfi 144) instead
of (scheme flonum). This can be handled via the library cond-expand
syntax,
(so the "prelude" is a library that wraps the benchmark. The benchmark
program then simply imports the library) but I expect the next release
to fix this small oversight. Its trivial for a user to provide a
(scheme flonum) library via SRFI 138. Both Larceny and Chibi support
this, and I use it with my benchmarking framework.

I encourage implementers to support SRFI 138 for this reason - it
solves so many problems like this. All the benchmarking "preludes"
simply become wrappers and appended libraries. In the worst case, SRFI
144 can be defined in terms of R7RS Small.

So R7RS Small plus SRFI 144 are sufficient to run fft. When (scheme
flonum) is available, that could be used instead. Everything needed
is already there. Right now, you can run the benchmarks - including
fft - using R7RS Small plus parts of the Tangerine edition.

Is this what you mean when you refer to a Medium dialect? I have no
problem with that. Its just an alternative to the Large subset. This
isn't a zero-sum game, so we can have both. The main requirement is
for the subsets to be clearly defined. Then we can correctly label the
Scheme systems that support them. If Medium is a subset of Large, then
some systems can support Small, Medium and Large, while other systems
can support only Small and Medium, and some can support only Small.

However, right now, we have a lot of Partial systems. AIUI, this
applies only to R7RS Small systems. So the Medium and Large subsets
can also be Partial, but this is implicit in their definitions? Is
that correct?

[Marc Nieper-Wißkirchen]

Am Mo., 7. März 2022 um 22:16 Uhr schrieb Daphne Preston-Kendal
<d...@nonceword.org>:

> From the Yellow Edition:
> • syntax-case; to be extended by low-level syntax object destructuring procedures (; possibly to be defined in the spec in terms of Flatt's sets of scopes rather than Dybvig's marks and substitutions as in R6RS (the two models are semantically equivalent, but the former is simpler and more elegant imo)

NB: It isn't true that the sets of scopes model is equivalent to the
mark and substitutions model. The sets of scopes model becomes quite
complicated as soon as definition contexts (which Scheme has) have to
be supported, and here is where Racket's sets of scopes model differs
from the RnRS model.

An example given by Matthew Flatt himself is:

(define-syntax def-m
(syntax-rules ()
((def-m m given-x)
(begin
(define x 1)
(define-syntax m
(syntax-rules ()
((m)
(begin
(define given-x 2)
x))))))))

(def-m m x)
(m)

expanded in definition context. In R[567]RS, it is well-defined and
the final expression evaluates to 1 (and it is quite easy to see why);
in Racket, it is an error.

Marc

PS Low-level syntax object destructuring procedures should be
considered derived procedures and are a good fit for one of the
libraries in the large language, IMO. Racket needs something like
syntax->list because Racket's syntax form works differently from
R6RS's. With the R6RS semantics of the syntax form, there's no need
for such a procedure. In fact, one can make the case that syntax-case
is the correct primitive for the abstract (co-)inductive data type of
syntax objects. (Similar, for streams, not stream-null?, stream-pair?,
stream-car, stream-cdr, but a not-yet-specified stream-case is the
fundamental destructor.)

[Dr. Arne Babenhauserheide]

Martin Rodgers <mcro...@gmail.com> writes:

> On 08/03/2022, Dr. Arne Babenhauserheide <arne...@web.de> wrote:
>>
>> Martin Rodgers <mcro...@gmail.com> writes:
>>
>>> On 07/03/2022, Dr. Arne Babenhauserheide <arne...@web.de> wrote:
>>>> ¹: https://github.com/ecraven/r7rs-benchmarks/tree/master/src
>>>> ²: https://ecraven.github.io/r7rs-benchmarks/
>>>
>>> Is R7RS Small not enough to write a benchmarking tool?
>>
>> My point isn’t the benchmarking tool, but the benchmarks.
>>
>> Some of those need preludes to work on the different Schemes.

> E.g. for the fft benchmarch, Larceny 1.3 requires (srfi 144) instead
> of (scheme flonum). This can be handled via the library cond-expand
> syntax,
> (so the "prelude" is a library that wraps the benchmark. The benchmark
> program then simply imports the library) but I expect the next release
> to fix this small oversight. Its trivial for a user to provide a
> (scheme flonum) library via SRFI 138. Both Larceny and Chibi support
> this, and I use it with my benchmarking framework.

That „we have to do something special to make them work“ is something
that I think is something a larger report could prevent.

> I encourage implementers to support SRFI 138 for this reason - it
> solves so many problems like this. All the benchmarking "preludes"
> simply become wrappers and appended libraries. In the worst case, SRFI
> 144 can be defined in terms of R7RS Small.

I want to have more libraries that I can simply drop into place.

> So R7RS Small plus SRFI 144 are sufficient to run fft. When (scheme
> flonum) is available, that could be used instead. Everything needed
> is already there. Right now, you can run the benchmarks - including
> fft - using R7RS Small plus parts of the Tangerine edition.
>
> Is this what you mean when you refer to a Medium dialect? I have no
> problem with that.

Yes. That’s what I think could help — to get as many Schemes as possible
on board with a subset of features that makes it possible to write as
many kinds of libraries as possible such that can be run in all those
Schemes.

Maximize number of libraries x Schemes they work on without changes.

> Its just an alternative to the Large subset. This
> isn't a zero-sum game, so we can have both.

Yes.

> However, right now, we have a lot of Partial systems. AIUI, this
> applies only to R7RS Small systems. So the Medium and Large subsets
> can also be Partial, but this is implicit in their definitions? Is
> that correct?

I think so, yes.

My guess is that many of the differences are unplanned — just something
someone didn’t add due to missing time. Having a clearly defined subset
might enable Scheme implementations to converge to a broader common
base.

[Marc Nieper-Wißkirchen]

Daphne, besides my points in the previous posts, there's another
problem with your idea of making `interactive' a cond-expand feature:
As cond-expand features are tied to the procedure `features', they
must be dynamic entities and not lexical ones; your `interactive', on
the other hand, needs to a lexical entity (which depends on the
lexical environment when `cond-expand' is evaluated). A future
standard could solve that issue by making `features' a macro, though.

Am Di., 8. März 2022 um 12:19 Uhr schrieb Marc Nieper-Wißkirchen
<marc....@gmail.com>:

[Linas Vepstas]

A short FYI comment about REPL-as-a-service, from a guile user.  FYI because maybe it's relevant to what you're discussing ...

I've got a large, complex C++ server that exports a custom guile REPL on a telnet port.  It is entirely unrelated to, different from the default guile REPL, for sundry technical reasons.  Which leads to comment #1: don't do anything that will make it harder to create custom REPL's. There were 3 or 4 things that made it "hard" to create a REPL:  (a) converting exceptions to/from C++/scheme transparently. (b) making sure that exiting the last instance of a REPL doesn't trash the main server, and that new REPL's can be started at any time without interfering with existing ones  (c) UTF-8 woes (d) performance (e) dribbling out stdout prints to the eagerly-awaiting REPL user, as long-running threads execute. (f) Allowing user to ctrl-C and get at least some debugging support.

As of yesterday, I have a new and deeply scary requirement I have no clue how to deal with: expose the REPL to untrusted users on the open internet.  A kind-of REPL-as-a-service.  A sandbox-REPL. A security nightmare.

To summarize:  In my use-case, I have exactly zero stand-alone, compiled scheme "programs", and am not interested in that use-case, at all. Everything I have is a collection of modules providing services on a server trying to meet demands and requirements from a disparate user base.  A high-performance, rock-solid network REPL is the only thing that matters.  (and fwiw, creating such a beast is not easy: although guile offers a network server, it is slow, buggy, crashy and not scalable.)

Oh, shoot: I should mention: a srfi for thread-management would be marvelous: something like "top", to view which REPL's and which threads are doing what, view lock contention, view disk-i/o wait status for that thread, ability to pause some threads... In my use-case, I have 5-6 REPL's sucking in data or sending it out, plus a handful which the operator can monitor status. Having a "top" for scheme would be fantastic!  (And yes, I know I could write such a srfi myself... I'm just sayin ...)

-- linas

--
You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/B2537400-980F-427B-B54E-BFE7A3DD8C20%40nonceword.org.

--

Patrick: Are they laughing at us?

Sponge Bob: No, Patrick, they are laughing next to us.

 

[Marc Nieper-Wißkirchen]

Am Di., 8. März 2022 um 14:54 Uhr schrieb Marc Nieper-Wißkirchen
<marc....@gmail.com>:
>

> Am Mo., 7. März 2022 um 22:16 Uhr schrieb Daphne Preston-Kendal
> <d...@nonceword.org>:
>
> > From the Yellow Edition:
> > • syntax-case; to be extended by low-level syntax object destructuring procedures (; possibly to be defined in the spec in terms of Flatt's sets of scopes rather than Dybvig's marks and substitutions as in R6RS (the two models are semantically equivalent, but the former is simpler and more elegant imo)

[...]

Daphne, your statement seems to imply that you find the marks &
substitutions model of R6RS harder to understand. Can you clarify what
you find hard to understand? I'm asking because I find that it can be
rather simply explained through the following principles:

(1) Each identifier occurring in the output of a macro transformer is
renamed except if that identifier already occurred in the input of the
macro transformer.
(2) Each identifier has a well-defined lexical environment.
(3) Resolving the binding of a renamed identifier starts by looking it
up in its lexical environment and, if it is unbound there, proceeds by
resolving the binding of the non-renamed identifier.
(4) Binding one renamed identifier binds another renamed identifier if
and only if both were renamed by the same macro use and if binding one
of the non-renamed identifiers would bind the other one of the
non-renamed identifiers.

(These principles apply, not coincidentally, to the ER model (and
syntax-rules) as well.)

[Daphne Preston-Kendal]

On 10 Mar 2022, at 21:36, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

> Daphne, your statement seems to imply that you find the marks &
> substitutions model of R6RS harder to understand. Can you clarify what
> you find hard to understand?

I understand it, I just find it a kludge. (Antimarks?) I’m think I’m not the only one.

Is there no way to make sets of scopes work properly for definition macros? What makes the example you gave so different from letrec* as far as the macro expander’s model of bindings is concerned? I notice while noodling around to try to find out by example what makes it so much trickier than letrec* that Racket also doesn’t allow define-syntax at the top of a letrec*, at least. Is that related? I’m confused.


Daphne

[Marc Nieper-Wißkirchen]

Am Fr., 11. März 2022 um 08:14 Uhr schrieb Daphne Preston-Kendal
<d...@nonceword.org>:
>

> On 10 Mar 2022, at 21:36, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:
>
> > Daphne, your statement seems to imply that you find the marks &
> > substitutions model of R6RS harder to understand. Can you clarify what
> > you find hard to understand?
>
> I understand it, I just find it a kludge. (Antimarks?) I’m think I’m not the only one.

Antimarks are just a (possible) implementation detail (and maybe
helpful to write down some formal semantics) to make sure that the
expander runs in linear time. To explain the model (and that's what
counts most), use my item (1) in place of any talk about antimarks.
(To describe ER macros, there's likewise no need to talk about
syntactic closures through which they may be realized.

> Is there no way to make sets of scopes work properly for definition macros? What makes the example you gave so different from letrec* as far as the macro expander’s model of bindings is concerned? I notice while noodling around to try to find out by example what makes it so much trickier than letrec* that Racket also doesn’t allow define-syntax at the top of a letrec*, at least. Is that related? I’m confused.

Sets of scopes do not forbid internal (syntax) definitions. It is just
there where the semantics of that model is different from the
semantics used in the Scheme reports so far. And it is also there
where sets of scopes lose much of their beauty IMO making the RnRS
approach look simple in comparison. I haven't investigated in detail
what Racket allows so I can't say anything at the moment about your
question about define-syntax at the top of letrec*.

Letrec* alone is much simpler than a body with definitions and syntax
definitions because a body is only equivalent to a letrec* after the
syntax definitions have been recorded and the body has been expanded.
So I don't really think that the question of how letrec* is expanded
is of much relevance here. When internal (syntax) definitions are
expanded, the corresponding environment is built incrementally, while
for constructs like letrec* or let-syntax with much simpler scoping
rules the environment can be built at once in a functional way.

In any case, I think that the task of conceiving R7RS-large and
finding enough implementers willing to integrate it is already
daunting enough so that we should not also replace the syntax model.
The RnRS model works (and it, at least in my opinion, simple) so
unless we want to incorporate all of Racket's syntactic facilities
(which would raise the question why we didn't abandon Scheme and turn
to Racket altogether) there's no need to do any replacement, which
would be just another of these gratuitous incompatibilities with
previous reports.

As a side note, let me remark that there are other differences between
Racket and RnRS not related to the expansion process but when it comes
to syntax objects. In native Racket, syntax objects are always fully
wrapped (which means that we need something like syntax->list), while
we have guarantees when syntax objects are not fully wrapped in RnRS.
The latter makes writing syntax transformers easier, the former makes
it possible to introduce things like #%app or #%quote in the language.

[Ondřej Majerech]

In my own Scheme I implemented set-of-scopes. The main reason for me was the availability of study material to base my implementation on. There's Flatt's paper which explains the model quite well and there's a Github repository with several example implementations of varying degrees of completeness that I could use to figure out any details the paper didn't talk about, which has been very helpful.

I'm not sure if there is anything similar for the R6RS model. If there is, it's more difficult to find than for the set-of-scopes model.

[Marc Nieper-Wißkirchen]

Am Sa., 12. März 2022 um 14:55 Uhr schrieb Ondřej Majerech
<oxyd...@gmail.com>:

>
> In my own Scheme I implemented set-of-scopes. The main reason for me was the availability of study material to base my implementation on. There's Flatt's paper which explains the model quite well and there's a Github repository with several example implementations of varying degrees of completeness that I could use to figure out any details the paper didn't talk about, which has been very helpful.
>
> I'm not sure if there is anything similar for the R6RS model. If there is, it's more difficult to find than for the set-of-scopes model.

There is Kent Dybvig's paper "Syntactic Abstraction: The syntax-case
expander" ([1]), for example. It contains a description and source
code as well.

I find reading the source code of Chez Scheme ([2]) also quite
enlightening to see how the things in [1] are implemented in an
industrial-strength Scheme.

--

[1] http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=5F148E93755BFADF2F297CBC66A09A4E?doi=10.1.1.304.7781&rep=rep1&type=pdf
[2] https://github.com/cisco/ChezScheme/blob/main/s/syntax.ss

> --
> You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/0da6e7b1-4590-4c2b-b598-b3ce73993080n%40googlegroups.com.

[Ondrej Majerech]

On Sat, 12 Mar 2022 at 15:39, Marc Nieper-Wißkirchen
<marc....@gmail.com> wrote:
>
> Am Sa., 12. März 2022 um 14:55 Uhr schrieb Ondřej Majerech
> <oxyd...@gmail.com>:
> >
> > In my own Scheme I implemented set-of-scopes. The main reason for me was the availability of study material to base my implementation on. There's Flatt's paper which explains the model quite well and there's a Github repository with several example implementations of varying degrees of completeness that I could use to figure out any details the paper didn't talk about, which has been very helpful.
> >
> > I'm not sure if there is anything similar for the R6RS model. If there is, it's more difficult to find than for the set-of-scopes model.
>
> There is Kent Dybvig's paper "Syntactic Abstraction: The syntax-case
> expander" ([1]), for example. It contains a description and source
> code as well.
>
> I find reading the source code of Chez Scheme ([2]) also quite
> enlightening to see how the things in [1] are implemented in an
> industrial-strength Scheme.

I personally find the Chez codebase quite impenetrable rather than enlightening.

> You received this message because you are subscribed to a topic in the Google Groups "scheme-reports-wg2" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/scheme-reports-wg2/WhimxJtpgqQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to scheme-reports-...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/CAEYrNrSTJ5P4i_XtpT9Oe%3DVNWa9rT3R4sEsGnj4xS87S92HAbA%40mail.gmail.com.

[Marc Nieper-Wißkirchen]

Am Sa., 12. März 2022 um 15:43 Uhr schrieb Ondrej Majerech
<oxyd...@gmail.com>:

>
> On Sat, 12 Mar 2022 at 15:39, Marc Nieper-Wißkirchen
> <marc....@gmail.com> wrote:
> >
> > Am Sa., 12. März 2022 um 14:55 Uhr schrieb Ondřej Majerech
> > <oxyd...@gmail.com>:
> > >
> > > In my own Scheme I implemented set-of-scopes. The main reason for me was the availability of study material to base my implementation on. There's Flatt's paper which explains the model quite well and there's a Github repository with several example implementations of varying degrees of completeness that I could use to figure out any details the paper didn't talk about, which has been very helpful.
> > >
> > > I'm not sure if there is anything similar for the R6RS model. If there is, it's more difficult to find than for the set-of-scopes model.
> >
> > There is Kent Dybvig's paper "Syntactic Abstraction: The syntax-case
> > expander" ([1]), for example. It contains a description and source
> > code as well.
> >
> > I find reading the source code of Chez Scheme ([2]) also quite
> > enlightening to see how the things in [1] are implemented in an
> > industrial-strength Scheme.
>
> I personally find the Chez codebase quite impenetrable rather than enlightening.

To find out more about the model and the algorithm, start with [1]. :)

> To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/CAF-qcqYBLsQyJUEDAeGR%3DKqUNQ9e1dM5GDqrJp9%3Drh%3D5ePdK6Q%40mail.gmail.com.

[Ondrej Majerech]

On Sat, 12 Mar 2022 at 15:50, Marc Nieper-Wißkirchen

<marc....@gmail.com> wrote:
>
> Am Sa., 12. März 2022 um 15:43 Uhr schrieb Ondrej Majerech
> <oxyd...@gmail.com>:
> >
> > On Sat, 12 Mar 2022 at 15:39, Marc Nieper-Wißkirchen
> > <marc....@gmail.com> wrote:
> > >
> > > Am Sa., 12. März 2022 um 14:55 Uhr schrieb Ondřej Majerech
> > > <oxyd...@gmail.com>:
> > > >
> > > > In my own Scheme I implemented set-of-scopes. The main reason for me was the availability of study material to base my implementation on. There's Flatt's paper which explains the model quite well and there's a Github repository with several example implementations of varying degrees of completeness that I could use to figure out any details the paper didn't talk about, which has been very helpful.
> > > >
> > > > I'm not sure if there is anything similar for the R6RS model. If there is, it's more difficult to find than for the set-of-scopes model.
> > >
> > > There is Kent Dybvig's paper "Syntactic Abstraction: The syntax-case
> > > expander" ([1]), for example. It contains a description and source
> > > code as well.
> > >
> > > I find reading the source code of Chez Scheme ([2]) also quite
> > > enlightening to see how the things in [1] are implemented in an
> > > industrial-strength Scheme.
> >
> > I personally find the Chez codebase quite impenetrable rather than enlightening.
>
> To find out more about the model and the algorithm, start with [1]. :)

I already read that. You seem to be missing the point. When I was
deciding which model to implement I looked at the mark-antimark paper
and looked around for implementations I could study. I also looked at
the set-of-scopes paper and looked at the example implementations
Flatt made. Having done that, I quickly came to the conclusion that
set-of-scopes would be easier due to the availability of material.
Understanding a model is all well and good, but if I am to actually
write computer code to implement the model I'm going to have to
understand the details as well.

Your earlier point was about the willingness of implementers to
implement a model. I agree with Daphne that set-of-scopes appears more
approachable and so I speculate that implementers might be more
willing to implement that than mark-antimark.

> To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/CAEYrNrRsH-e%3DT-xe5m-HcR_GQDNPF1ykHLSFV5GNUTv8O_RW2g%40mail.gmail.com.

[Marc Nieper-Wißkirchen]

Am Sa., 12. März 2022 um 16:01 Uhr schrieb Ondrej Majerech
<oxyd...@gmail.com>:

[...]

> I already read that. You seem to be missing the point. When I was
> deciding which model to implement I looked at the mark-antimark paper
> and looked around for implementations I could study. I also looked at
> the set-of-scopes paper and looked at the example implementations
> Flatt made. Having done that, I quickly came to the conclusion that
> set-of-scopes would be easier due to the availability of material.
> Understanding a model is all well and good, but if I am to actually
> write computer code to implement the model I'm going to have to
> understand the details as well.

Sure you have to and don't doubt that you are able to understand both
models well enough to implement them. :)

> Your earlier point was about the willingness of implementers to
> implement a model. I agree with Daphne that set-of-scopes appears more
> approachable and so I speculate that implementers might be more
> willing to implement that than mark-antimark.

My original point was that we mustn't introduce just another
incompatibility with earlier standards unless there is clear evidence
that something is fundamentally broken in an earlier standard.

So changing the model is not really an option. If someone came up with
a (modified) version of sets of scopes that is actually equivalent to
the RnRS model, things would be different and we could then follow
Daphne's suggestion to use that when writing down the semantics of the
R7RS Large macro expander. That said, while you agree with Daphne that
the sets of scopes model is simpler to understand, this is still
subjective as is my opinion that it is the other way round.

Marc

[Per Bothner]

On 3/12/22 05:55, Ondřej Majerech wrote:
> In my own Scheme I implemented set-of-scopes. The main reason for me was the availability of study material to base my implementation on. There's Flatt's paper which explains the model quite well and there's a Github repository with several example implementations of varying degrees of completeness that I could use to figure out any details the paper didn't talk about, which has been very helpful.

I've only glanced at Flatt's "Binding as Sets of Scopes", which I hadn't heard of before.
I wonder if it uses a similar idea as Kawa's implementation. See
https://www.gnu.org/software/kawa/internals/semantic-analysis.html
especially the "Hygienic macros" section.

During macro-expansion, Kawa creates a PatternScope to hold the bindings introduceted
by syntax-rules or syntax-case, and a TemplateScope for the scope introduced by a
(syntax ...) form. These are "intertwined" with the regular scopes from let, lambda,
and module (file/library) scopes.
--
--Per Bothner
p...@bothner.com http://per.bothner.com/

[Ondrej Majerech]

On Sat, 12 Mar 2022 at 16:19, Marc Nieper-Wißkirchen
<marc....@gmail.com> wrote:
>
> Am Sa., 12. März 2022 um 16:01 Uhr schrieb Ondrej Majerech
> <oxyd...@gmail.com>:
>
> [...]
>
> > I already read that. You seem to be missing the point. When I was
> > deciding which model to implement I looked at the mark-antimark paper
> > and looked around for implementations I could study. I also looked at
> > the set-of-scopes paper and looked at the example implementations
> > Flatt made. Having done that, I quickly came to the conclusion that
> > set-of-scopes would be easier due to the availability of material.
> > Understanding a model is all well and good, but if I am to actually
> > write computer code to implement the model I'm going to have to
> > understand the details as well.
>
> Sure you have to and don't doubt that you are able to understand both
> models well enough to implement them. :)
>
> > Your earlier point was about the willingness of implementers to
> > implement a model. I agree with Daphne that set-of-scopes appears more
> > approachable and so I speculate that implementers might be more
> > willing to implement that than mark-antimark.
>
> My original point was that we mustn't introduce just another
> incompatibility with earlier standards unless there is clear evidence
> that something is fundamentally broken in an earlier standard.

I quite disagree with this adversity toward backward-incompatible
changes in Scheme. Regarding the incompatibility you mentioned
earlier, Flatt in his paper says: “So far, we have not encountered a
practical example that exposes the difference between the expanders’
treatment of pattern-based macros in definition contexts.”

Thus, I think that instead of flat-out refusing a breaking change, the
correct first step would be to see how much actual code would be
broken by this change, and how difficult it would be to migrate the
broken code. If the answer is very little code would break and it
would be trivial to migrate, then it's a very different situation than
if a lot of code were to be broken and migrating were hard.

Flatt suggests that very little code would break and I feel inclined
to believe that.

>
> So changing the model is not really an option. If someone came up with
> a (modified) version of sets of scopes that is actually equivalent to
> the RnRS model, things would be different and we could then follow
> Daphne's suggestion to use that when writing down the semantics of the
> R7RS Large macro expander. That said, while you agree with Daphne that
> the sets of scopes model is simpler to understand, this is still
> subjective as is my opinion that it is the other way round.

No doubt it is subjective. The real question is how the community in
general feels, rather than any one of us individually.

>
> Marc

>
> --
> You received this message because you are subscribed to a topic in the Google Groups "scheme-reports-wg2" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/scheme-reports-wg2/WhimxJtpgqQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to scheme-reports-...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/CAEYrNrSqB5LLJ4VaFg8UswJOWLBfm_pQWtw7inVvwiE_6GeELw%40mail.gmail.com.

[Per Bothner]

On 3/12/22 07:44, Ondrej Majerech wrote:

> Thus, I think that instead of flat-out refusing a breaking change, the
> correct first step would be to see how much actual code would be
> broken by this change, and how difficult it would be to migrate the
> broken code. If the answer is very little code would break and it
> would be trivial to migrate, then it's a very different situation than
> if a lot of code were to be broken and migrating were hard.

Compare the Rationale for SRFI 140 "Immutable Strings".

[Marc Nieper-Wißkirchen]

Am Sa., 12. März 2022 um 16:45 Uhr schrieb Ondrej Majerech

If there is a clear gain, I will agree with all of what you have said. (*)

But unless someone points out such a clear gain, it would be foolish
to introduce incompatibilities even if they are minor.

There are not so many Scheme implementations that can compete with
top-notch implementations of other programming languages, so if R7RS
Large is to become successful as a practical and competitive
programming language, I firmly believe that we have to get these
implementations on board. This includes implementations of R6RS that
actually want to be R6RS-compatible not just a rough but a faithful
implementation of that standard. Telling them that R7RS Large uses an
R6RS-incompatible model because of some speculation that some
different model is simpler to understand would alienate them, I think.

I think it is time to bring together Scheme standards instead of
creating another split.

We shouldn't make it too hard to write implementations that try to be
100% compatible with the standards and that can also easily move
forward when a new standard is introduced.

(*) A semantic change happened between R5RS and R67RS with respect to
the semantics of the letrec form. The new version fixed the efficiency
problems with the old version and was an incompatible change to the
language. But here, the implementations could easily support both
versions and, moreover, there was a clear gain.

[Marc Nieper-Wißkirchen]

Am Sa., 12. März 2022 um 17:11 Uhr schrieb Per Bothner <p...@bothner.com>:
>
>
>
> On 3/12/22 07:44, Ondrej Majerech wrote:
>
> > Thus, I think that instead of flat-out refusing a breaking change, the
> > correct first step would be to see how much actual code would be
> > broken by this change, and how difficult it would be to migrate the
> > broken code. If the answer is very little code would break and it
> > would be trivial to migrate, then it's a very different situation than
> > if a lot of code were to be broken and migrating were hard.
>
> Compare the Rationale for SRFI 140 "Immutable Strings".

Indeed, this is just another good example of my point that some
tangible reward has to be gained. While SRFI 140 introduces some
incompatibilities, it does so to solve a real problem.

[Marc Nieper-Wißkirchen]

Am Fr., 11. März 2022 um 08:14 Uhr schrieb Daphne Preston-Kendal
<d...@nonceword.org>:

> Is there no way to make sets of scopes work properly for definition macros? What makes the example you gave so different from letrec* as far as the macro expander’s model of bindings is concerned? I notice while noodling around to try to find out by example what makes it so much trickier than letrec* that Racket also doesn’t allow define-syntax at the top of a letrec*, at least. Is that related? I’m confused.

Daphne, can you post the example that doesn't work with Racket's sets
of scopes model that has a define-syntax at the top of a letrec*?

[John Cowan]

On Sat, Mar 12, 2022 at 10:45 AM Ondrej Majerech <oxyd...@gmail.com> wrote:

Thus, I think that instead of flat-out refusing a breaking change, the
correct first step would be to see how much actual code would be
broken by this change, and how difficult it would be to migrate the
broken code. If the answer is very little code would break and it
would be trivial to migrate, then it's a very different situation than
if a lot of code were to be broken and migrating were hard.

The trouble is that we have no access to the total body of Scheme code.  There are clear indications that there is a great deal of closed-source Scheme out there.  Furthermore, if I understand correctly, the effects of this change are subtle and not necessarily visible by simple black-box testing.  This is what the C standards committee call a "silent breaking change", which is to be avoided at all costs.  

R6RS introduced just such a change into the `real?` procedure (and consequently into `rational?` and `integer?` as well.  In R5RS a number whose imaginary part is zero is always real, whereas in R6RS this is true only if it is an *exact* zero.  From a theoretical point of view this change improves the situation quite a bit, since an inexact zero might not be mathematically zero; it can be a non-zero number whose absolute value is less than the smallest representable float.  But the change was rejected by WG1 precisely because it may cause some code to break in ways that are not readily detectable.  We didn't object to adding new predicates with the R6RS interpretation, but could not come up with non-confusing names for them (we did not want to re-create the quo/rem/div/etc. situation).

Flatt suggests that very little code would break and I feel inclined
to believe that.

Racket provides easy access to a great deal of Racket code, but neither Flatt nor anyone else knows the ratio of inaccessible code to accessible code even in Racket, so such claims cannot be justified.

No doubt it is subjective. The real question is how the community in
general feels, rather than any one of us individually.

That's another thing no one can determine with high reliability for the same reason.

[Marc Nieper-Wißkirchen]

Am Sa., 12. März 2022 um 17:27 Uhr schrieb John Cowan <co...@ccil.org>:

> The trouble is that we have no access to the total body of Scheme code. There are clear indications that there is a great deal of closed-source Scheme out there. Furthermore, if I understand correctly, the effects of this change are subtle and not necessarily visible by simple black-box testing. This is what the C standards committee call a "silent breaking change", which is to be avoided at all costs.

It would be interesting to know whether SRFI 148's source code, which
squeezes every bit out of what R[67]RS syntax-rules are capable of,
still works when run under the different hygiene model.

NB: We have been talking about sets of scopes vs the R6RS syntax-case
model but the hygiene model implemented by ER is the same as R6RS's
model so these minor incompatibilities will affect a majority of
existing Schemes but Racket.

> R6RS introduced just such a change into the `real?` procedure (and consequently into `rational?` and `integer?` as well. In R5RS a number whose imaginary part is zero is always real, whereas in R6RS this is true only if it is an *exact* zero. From a theoretical point of view this change improves the situation quite a bit, since an inexact zero might not be mathematically zero; it can be a non-zero number whose absolute value is less than the smallest representable float. But the change was rejected by WG1 precisely because it may cause some code to break in ways that are not readily detectable. We didn't object to adding new predicates with the R6RS interpretation, but could not come up with non-confusing names for them (we did not want to re-create the quo/rem/div/etc. situation).

Your last sentence raises a very good point. Even if one
implementation supports only "the wrong" of the two interpretations of
`real?' natively, it can easily provide the other one by exposing the
corresponding predicate in the respective standard library. In other
words, a Scheme system can easily support R6RS and R7RS at the same
time (with respect to this question) and can also easily mix R6RS and
R7RS libraries. The same Scheme system, however, cannot easily support
two hygiene models at the same time.

[Ondrej Majerech]

On Sat, 12 Mar 2022 at 17:27, John Cowan <co...@ccil.org> wrote:
>
>
>
> On Sat, Mar 12, 2022 at 10:45 AM Ondrej Majerech <oxyd...@gmail.com> wrote:
>>
>> Thus, I think that instead of flat-out refusing a breaking change, the
>> correct first step would be to see how much actual code would be
>> broken by this change, and how difficult it would be to migrate the
>> broken code. If the answer is very little code would break and it
>> would be trivial to migrate, then it's a very different situation than
>> if a lot of code were to be broken and migrating were hard.
>
>
> The trouble is that we have no access to the total body of Scheme code. There are clear indications that there is a great deal of closed-source Scheme out there. Furthermore, if I understand correctly, the effects of this change are subtle and not necessarily visible by simple black-box testing. This is what the C standards committee call a "silent breaking change", which is to be avoided at all costs.

I don't think you do understand correctly. What we have here is an
example of code that is accepted by a mark-antimark implementation,
but fails to compile under a set-of-scopes implementation. Definitely
not silent.

Regarding access to the total body of Scheme code, that is a given.
Nevertheless, the accessible body of open-source code can still be
analysed as a representative sample of the total body of Scheme code.

>
> R6RS introduced just such a change into the `real?` procedure (and consequently into `rational?` and `integer?` as well. In R5RS a number whose imaginary part is zero is always real, whereas in R6RS this is true only if it is an *exact* zero. From a theoretical point of view this change improves the situation quite a bit, since an inexact zero might not be mathematically zero; it can be a non-zero number whose absolute value is less than the smallest representable float. But the change was rejected by WG1 precisely because it may cause some code to break in ways that are not readily detectable. We didn't object to adding new predicates with the R6RS interpretation, but could not come up with non-confusing names for them (we did not want to re-create the quo/rem/div/etc. situation).
>>
>>
>> Flatt suggests that very little code would break and I feel inclined
>> to believe that.
>
>
> Racket provides easy access to a great deal of Racket code, but neither Flatt nor anyone else knows the ratio of inaccessible code to accessible code even in Racket, so such claims cannot be justified.
>
>> No doubt it is subjective. The real question is how the community in
>> general feels, rather than any one of us individually.
>
>
> That's another thing no one can determine with high reliability for the same reason.
>

> --
> You received this message because you are subscribed to a topic in the Google Groups "scheme-reports-wg2" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/scheme-reports-wg2/WhimxJtpgqQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to scheme-reports-...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/CAD2gp_S0Md_aL%2BmOhV5ubY_3iVtRzD%3D800Zk_Qk6D%3D6SwCstBw%40mail.gmail.com.

[John Cowan]

On Sat, Mar 12, 2022 at 11:45 AM Ondrej Majerech <oxyd...@gmail.com> wrote:

 

I don't think you do understand correctly. What we have here is an
example of code that is accepted by a mark-antimark implementation,
but fails to compile under a set-of-scopes implementation. Definitely
not silent.

Sure, that is a consequence of Dijkstra's rule of testing: it can expose the presence of bugs but not their absence.  My concern is that if we moved to the new model, there might be plenty of code that compiled and behaved correctly in many circumstances *but not all*, and that we have no way of determining the relative importance of those circumstances.

Regarding access to the total body of Scheme code, that is a given.
Nevertheless, the accessible body of open-source code can still be
analysed as a representative sample of the total body of Scheme code.

I think it is very unlikely that it is representative.  When closed-source code becomes available through a security breach, there is always talk about "Now we can make an open-source version of well-known application X based on this!"  But it usually turns out that the code is junk and nobody in the open-source world can afford to do the necessary repairs to make it not junk: it's cheaper to create a green-field version.  Sun's open sourcing of Mozilla and Java are counterexamples, but Sun had at the time a very substantial income stream that they could afford to burn on such things.

[Marc Nieper-Wißkirchen]

Am Sa., 12. März 2022 um 17:53 Uhr schrieb John Cowan <co...@ccil.org>:

> On Sat, Mar 12, 2022 at 11:45 AM Ondrej Majerech <oxyd...@gmail.com> wrote:
>
>>
>> I don't think you do understand correctly. What we have here is an
>> example of code that is accepted by a mark-antimark implementation,
>> but fails to compile under a set-of-scopes implementation. Definitely
>> not silent.

It does not only break code that works under a marks & substitutions
implementation but also under any ER implementation of syntax-rules.
And the behavior of the latter is part of previous RnRS, so it is not
just some implementation artifact.

I can be persuaded to support a change if someone comes up with a
convincing argument that the sets and scopes model will significantly
improve the expressiveness of R7RS Large.

For sure, it would enable us to import all of Racket's plethora of
syntactic abstractions but then we would need someone to maintain it
within the standard and it would raise the question of how different
the resulting standard (in terms of existing implementations and
semantics) would be from Racket. Moreover, the latest ballot would
probably have to be reviewed.

[Daphne Preston-Kendal]

Oh, duh, it appears the actual problem was that Racket does not define a thing called letrec* (its letrec is everyone else’s letrec*, it seems) — so it thought my macro expansion was a call to a function called letrec* and I was trying to pass the output of define-syntax as an argument.

Apologies for the red herring.


Daphne

[Linas Vepstas]

I have some very naive questions:

On Sat, Mar 12, 2022 at 10:44 AM Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

It would be interesting to know whether SRFI 148's source code, which
squeezes every bit out of what R[67]RS syntax-rules are capable of,
still works when run under the different hygiene model.

What's the story with unit tests?  Do most srfi's come with unit tests? Are they extensive or superficial?  In my experience, unit tests are a great way to detect breakages caused by seemingly-minor changes. 

(In my own case, I'm the beneficiary of a decades worth of unit tests: every time some user complains about something being broken, that becomes a new unit test.  I am often surprised when I run them: they frequently report that obviously-safe, minor changes are in fact not safe, after all. They also reveal exactly where the old, bad design choices were made. -- thus allowing them to be reworked, without hurting everything else.  I used to be a seat-of-the-pants programmer, still am, for most-other things. But for the kind of stuff being talked about here ... my experience says that unit tests are the correct approach.)

--linas

[Arthur A. Gleckler]

On Sat, Mar 12, 2022 at 9:33 AM Linas Vepstas <linasv...@gmail.com> wrote:

 

What's the story with unit tests?  Do most srfi's come with unit tests? Are they extensive or superficial?  In my experience, unit tests are a great way to detect breakages caused by seemingly-minor changes. 

 

Unit tests were not always required for SRFIs, but they are required now, with few exceptions.

[Marc Nieper-Wißkirchen]

As part of another discussion, Daphne told me that according to her
experiments the following example (I brought up in that discussion)

(define-syntax bar
(let ((var #'x))
(lambda (stx)
#`(let ((x 10)) #,var))))
(bar)

yields an undefined variable error in Kawa. The R6RS-compliant answer
would be 10 (*).

The set of scopes model of Racket evaluates the expression (bar) to 10
so it's not Kawa's model.

(In fact, the incompatibility of Racket's model with R6RS that I
mentioned above is minor when compared with the difference in the
behavior of this bar example. Implementations that differ in the bar
example, give (syntax ...) quite a different semantics than R6RS does,
and such definitely will affect non-trivial macro code.)

Marc

(*) From the spec, the above example must be equivalent to

(define-syntax bar
(lambda (stx)
(let ((var #'x))
#`(let ((x 10)) #,var))))
(bar)

In other words, in R6RS syntax objects are nothing special but be
hoistable like other literals.

[Vincent Manis]

On 2022-03-12 9:38 a.m., Arthur A. Gleckler wrote:

Unit tests were not always required for SRFIs, but they are required now, with few exceptions.

That's excellent news, as it implies that it might be reasonable to construct (by accretion) a test suite for Large, and for Medium, if that goes ahead. (If Medium happens, then presumably its test suite would be a subset of Large's, so no effort would be wasted.) This in no way need delay the Large and Medium efforts, as the test suite need not necessarily be released at the same time as the corresponding Reports. It also suggests that the unit test framework could be included in Medium, thus encouraging users of the language to adopt this framework. (SRFI 64 could be used, and thus added to an upcoming Large docket.) Furthermore, studying the test suite can help in understanding a given specification.

I recall that Aubrey Jaffer had a test suite for R4RS or maybe R5RS. Most of his test cases were in fact taken right from the examples in the corresponding report. That strikes me as an excellent way to go.

I am well aware of all the objections to unit tests. I spent years managing the teaching of software engineering to software developers in a large multinational company, I heard all the objections. Yes, you can never find all the necessary tests. Yes, some of your tests themselves may be wrong. In any case, a given implementation will still require some extra tests, e.g., for the GC.

But we don't need to let the perfect be the enemy of the good. The implementer gets no benefit (in particular, no certification) apart from a pleasant feeling as their implementation passes the test suite, so the only onus on the authors of the test suite is to do the best job they can. They can't be sued if an implementation that passes the test suite goes on to do fail in a horrible way in production. The fact that there may (almost certainly will) still be bugs lurking around after passing the suite shouldn't stop people from using the suite to catch lower-hanging fruit. And nothing (other than the work required) stops there from being a second, more comprehensive version with even more special fruit-catching goodness.

-- vincent

[Amirouche Boubekki]

On Sat, Mar 12, 2022 at 3:43 PM Ondrej Majerech <oxyd...@gmail.com> wrote:

> I personally find the Chez codebase quite impenetrable rather than enlightening.

Yes, I used to think that too. It is easier when you have a goal in mind.

Here is a diff [0] where:

- it allows numbers as library names;
- library to file path lookup algorithm for (foo bar) will first look
for the file foo/bar/bar.sld then foo/bar.sld (inpsired from gambit)
- Register `.sld` extension as a valid library extension;
- Very minimal `define-library` top level form;

[0] https://github.com/amirouche/arew/pull/2/files#diff-263ef32378d5a4e8892cc79c355843d58a3eb5404d32438373f7d4e2b7631b10

[Ondrej Majerech]

I'm sorry, how does that relate to Chez's macro expander?

>
> --
> You received this message because you are subscribed to a topic in the Google Groups "scheme-reports-wg2" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/scheme-reports-wg2/WhimxJtpgqQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to scheme-reports-...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/CAL7_Mo9HLH5Pbq1BkPaAqW1nEY9ePCJXuZDLhiH1wb0%2BNJhHmA%40mail.gmail.com.

[Marc Nieper-Wißkirchen]

Am So., 13. März 2022 um 19:35 Uhr schrieb Amirouche Boubekki
<amirouche...@gmail.com>:

>
> On Sat, Mar 12, 2022 at 3:43 PM Ondrej Majerech <oxyd...@gmail.com> wrote:
>
> > I personally find the Chez codebase quite impenetrable rather than enlightening.
>
> Yes, I used to think that too. It is easier when you have a goal in mind.
>
> Here is a diff [0] where:
>
> - it allows numbers as library names;

This is not compatible with some of Chez's syntactic extensions. Local
modules/imports need the last part of a library name to be a symbol,
not a number.

[Per Bothner]

On 3/12/22 12:13, Marc Nieper-Wißkirchen wrote:
> As part of another discussion, Daphne told me that according to her
> experiments the following example (I brought up in that discussion)
>
> (define-syntax bar
> (let ((var #'x))
> (lambda (stx)
> #`(let ((x 10)) #,var))))
> (bar)
>
> yields an undefined variable error in Kawa. The R6RS-compliant answer
> would be 10 (*).

> (*) From the spec, the above example must be equivalent to
>
> (define-syntax bar
> (lambda (stx)
> (let ((var #'x))
> #`(let ((x 10)) #,var))))
> (bar)

They are both equivalent in Kawa.

The two x-es come from two different templates (distinct syntax forms),
hence two different scopes that are not nested in each other.
So the two x-es are distinct - and one should *not* match the other.
Intuitively, it seems to me that Kawa is more "hygienically correct" and
other implementations are wrong:

"contextual information associated both with the input and with the tem
template is retained in the output to support lexical scoping" [r6rs-lib]

What I've always hated about syntax-case was that it seemed to be
specification-by-implementation - and a complicated implementation
that never made sense to me, nor had a clear connection to the concept
of hygiene: "marks" and "anti-marks" - give me a break. Most of Dybvig's paper
as I recall was "here are some neat examples of things we can do".

For that matter, R6RS is also excessively vague IMO - there is no clear
semantic model.

> The set of scopes model of Racket evaluates the expression (bar) to 10
> so it's not Kawa's model.

It still could be the same basic model but with some minor difference (or bug).

[Marc Nieper-Wißkirchen]

Am Mo., 14. März 2022 um 00:37 Uhr schrieb Per Bothner <p...@bothner.com>:
>
> On 3/12/22 12:13, Marc Nieper-Wißkirchen wrote:
> > As part of another discussion, Daphne told me that according to her
> > experiments the following example (I brought up in that discussion)
> >
> > (define-syntax bar
> > (let ((var #'x))
> > (lambda (stx)
> > #`(let ((x 10)) #,var))))
> > (bar)
> >
> > yields an undefined variable error in Kawa. The R6RS-compliant answer
> > would be 10 (*).
>
> > (*) From the spec, the above example must be equivalent to
> >
> > (define-syntax bar
> > (lambda (stx)
> > (let ((var #'x))
> > #`(let ((x 10)) #,var))))
> > (bar)
>
> They are both equivalent in Kawa.

So if that's the case, Kawa is even less compatible with syntax-case
R6RS. It seems that you implement something like SRFI 72, then.

> The two x-es come from two different templates (distinct syntax forms),
> hence two different scopes that are not nested in each other.
> So the two x-es are distinct - and one should *not* match the other.
> Intuitively, it seems to me that Kawa is more "hygienically correct" and
> other implementations are wrong:
>
> "contextual information associated both with the input and with the tem
> template is retained in the output to support lexical scoping" [r6rs-lib]

The syntax-case model distinguishes between renaming and between
contextual information. Two identifiers can be bound-identifier=?
without being free-identifier=? and vice versa. Renaming ("attaching a
mark") happens exactly once per macro call.

> What I've always hated about syntax-case was that it seemed to be
> specification-by-implementation - and a complicated implementation
> that never made sense to me, nor had a clear connection to the concept
> of hygiene: "marks" and "anti-marks" - give me a break. Most of Dybvig's paper
> as I recall was "here are some neat examples of things we can do".

The R6RS (and SRFI 93) defines its semantics; it uses operational
semantics with marks and anti-marks but this is "as if" and actual
implementations can use whatever algorithm gives the same semantics.

For more formal semantics, the R6RS suggests O. Waddell's Ph.D.
thesis, which includes the model in mathematical terms.

> For that matter, R6RS is also excessively vague IMO - there is no clear
> semantic model.

What is unclear? Maybe I could try and write up it in a way people find clearer.

In an earlier post in this thread, I wrote down the following
principles underlying the semantics:

(1) Each identifier occurring in the output of a macro transformer is
renamed except if that identifier already occurred in the input of the
macro transformer.
(2) Each identifier has a well-defined lexical environment.
(3) Resolving the binding of a renamed identifier starts by looking it
up in its lexical environment and, if it is unbound there, proceeds by
resolving the binding of the non-renamed identifier.
(4) Binding one renamed identifier binds another renamed identifier if
and only if both were renamed by the same macro use and if binding one
of the non-renamed identifiers would bind the other one of the
non-renamed identifiers.

I could describe that in detail.

In the bar example from above, one instance of x in the macro output
will bind the other instance of x in the macro output because they are
both renamed by the same macro use, and the non-renamed versions are
both just given by the same symbolic name x.

> > The set of scopes model of Racket evaluates the expression (bar) to 10
> > so it's not Kawa's model.
>
> It still could be the same basic model but with some minor difference (or bug).

The difference is not minor in the sense that any non-trivial, longer
syntax-case macro will break when you replace R6RS's model with SRFI
72.

Marc

[Daphne Preston-Kendal]

On 14 Mar 2022, at 00:36, Per Bothner <p...@bothner.com> wrote:

> What I've always hated about syntax-case was that it seemed to be
> specification-by-implementation - and a complicated implementation
> that never made sense to me, nor had a clear connection to the concept
> of hygiene: "marks" and "anti-marks" - give me a break. Most of Dybvig's paper
> as I recall was "here are some neat examples of things we can do".
>
> For that matter, R6RS is also excessively vague IMO - there is no clear
> semantic model.

This sort of complaint about the mark-antimark model is why I suggested that R7RS should switch to defining syntax expansion in terms of sets of scopes. I made the suggestion on the assumption that the two models are equivalent in all externally observable characteristics (with regard only to the R6RS syntax libraries, anyway — Flatt mentions incompatibilities in real-world code in his original paper under ‘Implementation and Experiences’, but the ones he does mention are to do with procedural macros using Racket extensions to the R6RS libraries).

But that is not actually the case, and the difference can be seen even in pure syntax-rules macros, never mind procedural ones. (As pointed out by Marc, this is mentioned in section 2.5 of Flatt’s paper.) But if it did help implementer uptake of the R7RS, perhaps we could simply swallow this difference — as Flatt says in his paper, no Racket module (and there are a lot, often using macros in quite advanced ways) has actually run across the difference to their knowledge.


Daphne

[Marc Nieper-Wißkirchen]

Am Mo., 14. März 2022 um 08:16 Uhr schrieb Daphne Preston-Kendal
<d...@nonceword.org>:
>

Now we are mixing three things. Kawa's model (possibly SRFI 72), the
R6RS model, and Racket's model. If you change the R6RS model into the
Racket model, this won't make a change for Per who believes Kawa's
model to be more hygienic (because Racket's model here is the same as
R6RS's model). You will find supporters for each of the three models
(and perhaps for two further models out there we don't know of yet). I
don't think that there is an alternative to sticking to backward
compatibility in particular as otherwise even plain-old syntax-rules
would be affected (not by Kawa's model this time, but by Racket's) and
because the R6RS model is not broken.

Speaking of helping implementers, I'd rather write down a hopefully
more helpful description of the RnRS model. If we do this, we may be
able to find a description in terms of a suitably modified sets of
scopes model that is actually observably equivalent.

[Daphne Preston-Kendal]

Alternatively — if we were willing to swallow some small amount of R6RS compatibility anyway for the sake of implementer engagement — we could switch to the SRFI 72 model of hygiene. But I think that would be much more likely to break real-world macros.


Daphne

> --

> You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/CD4817EC-2521-4F9B-87B0-67331CE8AB64%40nonceword.org.

[Marc Nieper-Wißkirchen]

Am Mo., 14. März 2022 um 08:31 Uhr schrieb Daphne Preston-Kendal
<d...@nonceword.org>:
>

> Alternatively — if we were willing to swallow some small amount of R6RS compatibility anyway for the sake of implementer engagement — we could switch to the SRFI 72 model of hygiene. But I think that would be much more likely to break real-world macros.

Yes, it would. (And it would not be a "small amount" and certainly
much larger than the difference between syntax-case and sets of
scopes.)

And practical macro writing of larger macros (I am talking about
macros that are implemented in 1000 lines or so) will become
significantly more laborious because you will have to pass a lot of
identifiers around and you can't just recreate them.

In any case, I don't think this is an option unless we want to remove
Chez from the list of possible implementations supporting R7RS.

[Per Bothner]

On 3/13/22 23:56, Marc Nieper-Wißkirchen wrote:
> So if that's the case, Kawa is even less compatible with syntax-case
> R6RS. It seems that you implement something like SRFI 72, then.

Based on a quick look at the ChangeLog, it looks like the Kawa
macro-expansion code mostly dates from 2004, wityh some changes around 2009
to support SRFI-72-style car/cdr on syntax object lists.
So my memory is understandably hazy. I had forgotten about SRFI-72
until you reminded me, but I suspect you're right.

> In the bar example from above, one instance of x in the macro output
> will bind the other instance of x in the macro output because they are
> both renamed by the same macro use, and the non-renamed versions are
> both just given by the same symbolic name x.

Kawa has the concept of a TemplateScope which identifies where a
macro-introduced identifier comes from. (A syntax object is a plain
datum along with a TemplateScope to interpret the datum in.)
In Kawa, a fresh TemplateScope is created each time a syntax form (or
quasisyntax form) is evaluated. An R6RS-compatible equivalent
would be to instead create a TemplateScope when a transformer (a macro)
is called. That would complicate how transformers are called,
but it is probably possible while still using similar scope structures.

However, the Kawa/SRFI-72 seems cleaner to me. The basic idea of a transformer
is a procedure that maps syntax objects to syntax objects. If a "transformer
call" has the added property of creating a new template-scope it becomes
more "magical" and harder to understand. On the other hand, syntax/quasisyntax
forms are explicit in the source code, and it seems much simpler and natural
to create the template-scopes in conjunction with evaluating syntax/quasisyntax.

Regardless: this was all a long time ago; my memory is hazy; the code
(and subject matter) is tricky and fragile; most examples and code
work fine either way; and I'm busy. So I'm unlikely to delve back into this area
anytime soon.

The SRFI-72 model has the nice feature that syntax object lists are actual lists
can be destructured and examined by standard list procedures such as car/cdr,
without having to use syntax-case. I kinda like that.

> The difference is not minor in the sense that any non-trivial, longer
> syntax-case macro will break when you replace R6RS's model with SRFI
> 72.

"Any"? The Kawa implementation has been used to compile quite a bit
of third-party code over the years, mostly without much trouble
(as far as I know). Most likely very few people write "non-trivial, longer
syntax-case macros".

[Marc Nieper-Wißkirchen]

Am Mo., 14. März 2022 um 16:02 Uhr schrieb Per Bothner <p...@bothner.com>:

> > The difference is not minor in the sense that any non-trivial, longer
> > syntax-case macro will break when you replace R6RS's model with SRFI
> > 72.
>
> "Any"? The Kawa implementation has been used to compile quite a bit
> of third-party code over the years, mostly without much trouble
> (as far as I know). Most likely very few people write "non-trivial, longer
> syntax-case macros".

You are right, "any" is only correct if "any" means "a macro that breaks" :).

By "non-trivial, longer syntax-case macros" I mean macros like those
of the nanopass framework ([1]).

These are the macros that matter most IMO because the small ones (e.g.
those used to define derived forms of the Scheme reports) can easily
be converted between different models (if they notice any difference
at all as you say).

--

[1] https://github.com/nanopass/nanopass-framework-scheme/tree/main/nanopass

[Marc Nieper-Wißkirchen]

Am Mo., 14. März 2022 um 16:02 Uhr schrieb Per Bothner <p...@bothner.com>:

> Kawa has the concept of a TemplateScope which identifies where a
> macro-introduced identifier comes from. (A syntax object is a plain
> datum along with a TemplateScope to interpret the datum in.)
> In Kawa, a fresh TemplateScope is created each time a syntax form (or
> quasisyntax form) is evaluated. An R6RS-compatible equivalent
> would be to instead create a TemplateScope when a transformer (a macro)
> is called. That would complicate how transformers are called,
> but it is probably possible while still using similar scope structures.
>
> However, the Kawa/SRFI-72 seems cleaner to me. The basic idea of a transformer
> is a procedure that maps syntax objects to syntax objects. If a "transformer
> call" has the added property of creating a new template-scope it becomes
> more "magical" and harder to understand. On the other hand, syntax/quasisyntax
> forms are explicit in the source code, and it seems much simpler and natural
> to create the template-scopes in conjunction with evaluating syntax/quasisyntax.

The semantics of a transformer in R6RS vs SRFI 72 is still that a
syntax object is mapped to a syntax object.

It is the expander when expanding a macro use that suitably renames
those identifiers in the macro output that weren't there in the macro
input.

I wouldn't say that any of the two models is "cleaner" than the other,
just different. In the SRFI 72 model, evaluating the syntax form
renames the identifiers; in the R6RS model (deriving from R4RS), the
renaming is part of the expansion process.

Writing longer macros seems to me to be more practical with the R6RS
model than with the SRFI 72 model, while the SRFI 72 model may help
prevent some unintended variable captures.

> Regardless: this was all a long time ago; my memory is hazy; the code
> (and subject matter) is tricky and fragile; most examples and code
> work fine either way; and I'm busy. So I'm unlikely to delve back into this area
> anytime soon.

A future version of Kawa that supports both models would be the best, of course.

> The SRFI-72 model has the nice feature that syntax object lists are actual lists
> can be destructured and examined by standard list procedures such as car/cdr,
> without having to use syntax-case. I kinda like that.

When do you want to destructure syntax objects using car/cdr in
practice (that is when writing practical macros)? Or, rather, when
would it be more convenient that destructuring using syntax-case?

Attaching source location information to syntax objects is also harder
in the SRFI 72 model and not possible to the fullest extent.

[...]

Marc

[Per Bothner]

I can't say. It has a certain elegance. I don't write many complicated Scheme
macros except to implement the Kawa language and libraries.

> Attaching source location information to syntax objects is also harder
> in the SRFI 72 model and not possible to the fullest extent.

Kawa has the advantage of having class inheritance. There are plain Pair
objects (created by cons). The Scheme reader creates a PairWithPosition,
which adds source location information (start and end position),
and inherits from ImmutablePair, which inherits from Pair.
A PairSyntaxForm extends ImmutablePair, while also wrapping a plain
Pair (usually a PairWithPosition) plus a TemplateScope.

So Kawa has pretty good source location information.

[Marc Nieper-Wißkirchen]

Am Mo., 14. März 2022 um 16:57 Uhr schrieb Per Bothner <p...@bothner.com>:

> > Attaching source location information to syntax objects is also harder
> > in the SRFI 72 model and not possible to the fullest extent.
>
> Kawa has the advantage of having class inheritance. There are plain Pair
> objects (created by cons). The Scheme reader creates a PairWithPosition,
> which adds source location information (start and end position),
> and inherits from ImmutablePair, which inherits from Pair.
> A PairSyntaxForm extends ImmutablePair, while also wrapping a plain
> Pair (usually a PairWithPosition) plus a TemplateScope.
>
> So Kawa has pretty good source location information.

Thanks for the detailed information!

Fast class inheritance really seems to be a big advantage for Kawa.
For most Schemes, it is probably too costly to have more than one
representation for pairs.

Do numbers and other constants also have derived versions that carry
source location information? (Again, this is something that is
probably out of reach for most Schemes when it comes to efficiency.)

[Per Bothner]

On 3/14/22 09:11, Marc Nieper-Wißkirchen wrote:
> Fast class inheritance really seems to be a big advantage for Kawa.
> For most Schemes, it is probably too costly to have more than one
> representation for pairs.
>
> Do numbers and other constants also have derived versions that carry
> source location information?

No. In almost all cases in Scheme code, source location for Pairs is enough:
The location of the 123 in (list 123 456) is the same is the location of
the cdr of the source list. For top-level non-list forms (such as a symbol foobar),
Kawa essentially wraps it in a dummy begin form (such as (begin foobar)).

There are two minor problems:
(1) The position of the list "(list 123 456)" is not the same as its
first element "list" - usually but not always they're 1 column different.
(2) The tails of improper lists don't have proper source information.

However, these are minor.

Source location could be added elsewhere. There is an abstract SourceLocator
interface, along with a default implementation (using a String filename along
with a 64-bit encoding of start+end line+column). This interface is also
implemented by Expression, SourceError, PairWithPositionSyntaxForm, and
other classes.

[John Cowan]

On Sat, Mar 12, 2022 at 11:14 AM Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

 

There are not so many Scheme implementations that can compete with
top-notch implementations of other programming languages, so if R7RS
Large is to become successful as a practical and competitive
programming language, I firmly believe that we have to get these
implementations on board.

I don't believe that will happen, for economic reasons.  Market-leading firms don't benefit from standardization unless they control it (which was the case for R6RS, if we believe as I do that Racket and Chez are market-leading).  On the contrary, they benefit from capturing their users and making it difficult to switch.  When they meet a standard that carries too much momentum, their strategy shifts to "embrace, expand, and extinguish". The beneficiary of standardization is consumers, especially those who are large enough to approach monopsony.

To make sure I am not misunderstood: I am not accusing the Racket and Chez teams of consciously and maliciously doing these things, but only of naturally following the same pattern as firms like Microsoft that do consciously use them for monopoly profits.

(Let me just mention that the statement "Racket supports R7RS-small" is not true in the economic sense.  There is a Small compatibility library on Racket written by an individual, but it is not part of Racket-the-firm's actual product.)

(*) A semantic change happened between R5RS and R67RS with respect to
the semantics of the letrec form. The new version fixed the efficiency
problems with the old version

Strictly speaking, R5RS's letrec was ambiguous between R6/R7RS letrec and letrec*.

[Marc Nieper-Wißkirchen]

Am Fr., 18. März 2022 um 02:31 Uhr schrieb John Cowan <co...@ccil.org>:

>> (*) A semantic change happened between R5RS and R67RS with respect to
>> the semantics of the letrec form. The new version fixed the efficiency
>> problems with the old version
>
>
> Strictly speaking, R5RS's letrec was ambiguous between R6/R7RS letrec and letrec*.

As R[67]RS letrec can, in principle, be implemented as an alias to
R[67]RS letrec*, I'm not sure whether this statement makes sense.

What I was referring to is that in R5RS it was allowed for the
initialization expressions to return more than once.

[Lassi Kortela]

> if R7RS Large is to become successful as a practical and competitive
> programming language, I firmly believe that we have to get these
> implementations on board.
>
> I don't believe that will happen, for economic reasons.  Market-leading
> firms don't benefit from standardization unless they control it (which
> was the case for R6RS, if we believe as I do that Racket and Chez are
> market-leading).  On the contrary, they benefit from capturing their
> users and making it difficult to switch.  When they meet a standard that
> carries too much momentum, their strategy shifts to "embrace, expand,
> and extinguish". The beneficiary of standardization is consumers,
> especially those who are large enough to approach monopsony.

These market dynamics are short-term phenomena. Lisp is a long-term
game. Standard Scheme will be here long after Racket is gone. The
further that Racket strays from RnRS and the more that it gobbles up new
features faster, the more it hastens its eventual obsolescence.

Apart from the long time horizon, Lisp advocacy and strategy should
start from "the [economic] pie gets bigger" line of thinking. It's
boring to be a big fish in a small pond. If Lisp dialects work together
more, we can grow the pond. If we're divisive, all of us will impress a
few friends and make a few enemies in some esoteric intellectual contest
that none of the people on the sidelines (who could help us) care much
about.