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.