Official Red Edition announcement; proposed library names; overlapping identifiers

[John Cowan]

This is the *very* belated announcement that the Red Edition of R7RS-large is officially complete.  This does not mean that R7RS-large as a whole is complete, far from it.  However, there are now a large number of SRFIs incorporated into the R7RS-large standard.  Development of SRFIs will continue for the Orange Edition, with a ballot in due course.  Other editions will follow the order of the spectrum until the final or Ultra-Violet edition is reached.

The following are the SRFIs that when combined with R7RS-small constitute the Red Edition, along with proposed library names (suggestions for different names are in order, though I hope to resolve any issues without a formal ballot):

SRFI 1 (scheme list)

SRFI 133 (scheme vector)

SRFI 132 (scheme sorting)

SRFI 113 (scheme set)

SRFI 114 (scheme set char)

SRFI 125 (scheme hash-table)

SRFI 116 (scheme list immutable)

SRFI 101 (scheme list random-access)

SRFI 134 (scheme deque immutable)

SRFI 135 (scheme textual)

SRFI 121 (scheme generator)

SRFI 128 (scheme lazy-seq)

SRFI 41 (scheme stream)

SRFI 111 (scheme box)

SRFI 117 (scheme list queue)

SRFI 124 (scheme ephemeron)

SRFI 128 (scheme comparator)

Special notes:  (scheme set) also includes bags, and (scheme stream) includes both the (streams primitive) and (streams derived) libraries of SRFI 41.

Note that these names are in the singular, both for compatibility with R7RS-small library names like (scheme char) and (scheme file), but also so that phrases like "the (scheme vector) library" will read naturally.

Finally, and as a matter of form, I propose that the libraries above in their (scheme *) form should exclude any identifiers also present in any R7RS-small library.  Thus for example (scheme list) will not export the primitive `car` function, which is in (scheme base), but also will not export the `cadr` function, which is in (scheme cxr).  This is already arranged for in all Schemes, as far as I know, that implement SRFI 1.

In this way, it is only necessary to import the (scheme *) libraries that a program needs, without any boilerplate to remove collisions between identifiers.  In all cases it has been been arranged that the definitions of identifiers also present in R7RS-small are identical with those present in the SRFI.

There is one exception to this: SRFI 101, where the names intentionally collide with names in (scheme base) or (scheme cxr).  I propose that this conflict be dealt with as follows:

make-list to become make-rlist

random-access-list->linear-access-list to become rlist->list

linear-access-list->random-access-list to become list->rlist

all other identifiers to be prefixed with "r" (rcons, rpair?, rcar, rmap, etc.)

-- 

John Cowan          http://www.ccil.org/~cowan        co...@ccil.org

weirdo:    When is R7RS coming out?

Riastradh: As soon as the top is a beautiful golden brown and if you

stick a toothpick in it, the toothpick comes out dry.

[Vincent Manis]

On 2016-08-26 09:16 PM, John Cowan wrote:

This is the *very* belated announcement that the Red Edition of R7RS-large is officially complete.  This does not mean that R7RS-large as a whole is complete, far from it.  However, there are now a large number of SRFIs incorporated into the R7RS-large standard.  Development of SRFIs will continue for the Orange Edition, with a ballot in due course.  Other editions will follow the order of the spectrum until the final or Ultra-Violet edition is reached.

This is excellent news! What additional work, if any, needs to be done to produce a consolidated Red Edition document? (I'm assuming that almost all of the text will be from the SRFIs, with the amendments John refers to.) I hope that the rationale sections of the SRFIs are not lost in this process, but end up in a parallel Rationale document.

And yes, I am offering to help in doing this.  -- vincent

[Will Clinger]

I noticed a couple of discrepancies between John's list of library names and
the library names given in the definition of RedEdition at
http://trac.sacrideo.us/wg/wiki/RedEdition

John Cowan wrote:

> SRFI 114 (scheme set char)

I believe this should be (scheme charset).  If not, then the WG2 definition of
RedEdition needs to be corrected.
 

> SRFI 117 (scheme list queue)

I believe this should be (scheme list-queue).  If not, then the WG definition of
RedEdition needs to be corrected.

> Finally, and as a matter of form, I propose that the libraries above in their (scheme *) form should exclude any identifiers also present in any R7RS-small library.  Thus for example (scheme list) will not export the primitive `car` function, which is in (scheme base), but also will not export the `cadr` function, which is in (scheme cxr).  This is already arranged for in all Schemes, as far as I know, that implement SRFI 1.

That last sentence is not true.  In my opinion, any implementation of SRFI 1
that fails to export car and cadr is simply broken.

WG2 can of course decide to make the (scheme list) library differ from the
(srfi 1) library.  I'd appreciate some kind of confirmation that WG2 has indeed
decided to go along with the "matter of form" John proposed above.

> In this way, it is only necessary to import the (scheme *) libraries that a program needs, without any boilerplate to remove collisions between identifiers.

There should be no collisions either way, because the car and cadr exported
by (scheme list) would be the same as car and cadr exported by (scheme base)
and (scheme cxr), but this will matter to programmers who (1) expect cadr to be
defined when they import (scheme list) without having to import (scheme cxr)
or (2) expect to define their own cadr when imported (scheme list).

Will

[Will Clinger]

Oops, I missed a third discrepancy:

> SRFI 132 (scheme sorting)

I believe that should be (scheme sort). If not, then the WG definition of

RedEdition needs to be corrected.

Will

[Will Clinger]

Oof.  There are lots of discrepancies.  Here are several more:

> SRFI 116 (scheme list immutable)

The RedEdition web page says that should be (scheme ilist).

> SRFI 101 (scheme list random-access)

The RedEdition web page says that should be (scheme rlist).

> SRFI 134 (scheme deque immutable)

The RedEdition page says that should be (scheme ideque).

> SRFI 135 (scheme textual)

The RedEdition page says that should be (scheme text).

> SRFI 128 (scheme lazy-seq)

That's SRFI 127, and the RedEdition page says that should be (scheme lseq).

I'm inclined to believe the RedEdition web page is authoritative, in which case
my questions can at least serve as a pointer to it:

 http://trac.sacrideo.us/wg/wiki/RedEdition

I'd still like to hear an authoritative answer to the question of whether (scheme list)
should export car and cadr.  For what it's worth, Sagittarius has (scheme list)
export cadr, and Sagittarius appears to be the only complete implementation of
R7RS Red Edition at the moment.  Larceny will join it shortly, which is why I'm
trying to nail this down.

Will

[John Cowan]

On Wed, Jun 28, 2017 at 6:14 PM, Will Clinger <cesu...@gmail.com> wrote:

I'm inclined to believe the RedEdition web page is authoritative 

That was my intention.  My earlier email was just a trial balloon.

I'd still like to hear an authoritative answer to the question of whether (scheme list)
should export car and cadr.

So would I.  Since no one has raised the point before, I will flip-flop and go with exporting the overlapping names (understanding that they have the same binding in both libraries rather than merely the same behavior), unless there is an objection on this list within a reasonable time.  If there is a further objection, we'll hold a ballot.

 -- 

John Cowan          http://vrici.lojban.org/~cowan        co...@ccil.org

The whole of Gaul is quartered into three halves.

        --Julius Caesar

[Alex Shinn]

2017/06/29 午前7:21 "John Cowan" <co...@ccil.org>:

On Wed, Jun 28, 2017 at 6:14 PM, Will Clinger <cesu...@gmail.com> wrote:

I'm inclined to believe the RedEdition web page is authoritative 

That was my intention.  My earlier email was just a trial balloon.

I'd still like to hear an authoritative answer to the question of whether (scheme list)
should export car and cadr.

So would I.  Since no one has raised the point before, I will flip-flop and go with exporting the overlapping names (understanding that they have the same binding in both libraries rather than merely the same behavior), unless there is an objection on this list within a reasonable time.  If there is a further objection, we'll hold a ballot.

I think there should be no difference between importing (scheme list) and (srfi 1), which must export car and cadr.  The bindings for R7RS libraries should be required to be the same.

-- 

Alex

 -- 

John Cowan          http://vrici.lojban.org/~cowan        co...@ccil.org

The whole of Gaul is quartered into three halves.

        --Julius Caesar

--
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-wg2+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Will Clinger]

I appreciate the quick answers.  While someone might yet object, I am proceeding
under the assumption that importing (scheme list) will be just like importing (srfi 1).
There will of course be no conflicts between (scheme list) and any of the other R7RS
Red Edition libraries.

There is, however, a conflict between (scheme comparator) and (scheme hash-table)
because the latter exports deprecated versions of string-hash and string-ci-hash that
accept an optional second argument.  In a way, that conflict serves a useful purpose
by underlining the deprecation.

The R7RS Red Edition added one new conflict between an R7RS library and an R6RS
library: the remove procedure of (scheme list) takes a predicate as its first argument,
but the remove procedure of (rnrs lists) takes an object to be removed; the R6RS
equivalent of R7RS remove is named remp.

Will

[John Cowan]

On Wed, Jun 28, 2017 at 8:23 PM, Will Clinger <cesu...@gmail.com> wrote:

There is, however, a conflict between (scheme comparator) and (scheme hash-table)
because the latter exports deprecated versions of string-hash and string-ci-hash that
accept an optional second argument.

I don't see this as actually a conflict.  Nothing prevents (scheme comparator) from exporting versions of the procedures that accept an optional argument.  It's an error to call them with a second argument, but such errors do not have to be detected at compile time or run time, though they can be.

 

The R7RS Red Edition added one new conflict between an R7RS library and an R6RS
library: the remove procedure of (scheme list) takes a predicate as its first argument,
but the remove procedure of (rnrs lists) takes an object to be removed; the R6RS
equivalent of R7RS remove is named remp.

I assume you'll be renaming the R6RS version to r6rs:remove in -r7r6 mode?

-- 

John Cowan          http://vrici.lojban.org/~cowan        co...@ccil.org

Rather than making ill-conceived suggestions for improvement based on

uninformed guesses about established conventions in a field of study with

which familiarity is limited, it is sometimes better to stick to merely

observing the usage and listening to the explanations offered, inserting

only questions as needed to fill in gaps in understanding. --Peter Constable

[Will Clinger]

John Cowan quoting me:

There is, however, a conflict between (scheme comparator) and (scheme hash-table)
because the latter exports deprecated versions of string-hash and string-ci-hash that
accept an optional second argument.

I don't see this as actually a conflict.  Nothing prevents (scheme comparator) from exporting versions of the procedures that accept an optional argument.  It's an error to call them with a second argument, but such errors do not have to be detected at compile time or run time, though they can be.

True.  OTOH, if the string-hash and string-ci-hash exported by (scheme comparator) were
the same as the deprecated versions exported by (scheme hash-table), they too would be
deprecated.  I prefer to confine the deprecation to identifiers exported by a single library.

The R7RS Red Edition added one new conflict between an R7RS library and an R6RS
library: the remove procedure of (scheme list) takes a predicate as its first argument,
but the remove procedure of (rnrs lists) takes an object to be removed; the R6RS
equivalent of R7RS remove is named remp.

I assume you'll be renaming the R6RS version to r6rs:remove in -r7r6 mode?

Yes.

The (larceny r7r6) library, implied by the --r7r6 option, will include the normal string-hash
and string-ci-hash but won't include the deprecated versions under any name.

Will

[Marc Nieper-Wißkirchen]

I'd still like to hear an authoritative answer to the question of whether (scheme list)
should export car and cadr.

So would I.  Since no one has raised the point before, I will flip-flop and go with exporting the overlapping names (understanding that they have the same binding in both libraries rather than merely the same behavior), unless there is an objection on this list within a reasonable time.  If there is a further objection, we'll hold a ballot.

I think there should be no difference between importing (scheme list) and (srfi 1), which must export car and cadr.  The bindings for R7RS libraries should be required to be the same.

I fully agree with this. However, R7RS-small is too much underspecified to make this work well in a portable manner: When I take the reference implementation of (srfi 1), which imports (scheme base) and re-exports the binding to, say, car, and a program imports (srfi 1) and (scheme base), it is not guaranteed that the bindings of car as exported by (srfi 1) and (scheme base), respectively, refer to the same locations because R7RS-small seems to make no guarantee that (scheme base) is loaded only once. The binding of car as exported by (srfi 1) may stem from a different loading than the binding as exported by the (scheme base) directly imported from the program.

Thus, for R7RS-large a more restricted specification of the loading process of libraries is urgently needed. For later referral, one may call this the "diamond-problem" of library loading/importing.

In fact, I would love to see a partial answer to this problem already in the (unofficial) errata to R7RS-small. Every implementation I have seen so far do not create more than one binding for all directly and indirectly imported identifiers from the import statements of a top-level program. And with no guarantee about this, using the module system of the R7RS efficiently is very hard, anyway. (Remember that define-record-type is generative...)

--

Marc

[Alex Shinn]

On Tue, Jul 4, 2017 at 3:59 PM, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

I'd still like to hear an authoritative answer to the question of whether (scheme list)
should export car and cadr.

So would I.  Since no one has raised the point before, I will flip-flop and go with exporting the overlapping names (understanding that they have the same binding in both libraries rather than merely the same behavior), unless there is an objection on this list within a reasonable time.  If there is a further objection, we'll hold a ballot.

I think there should be no difference between importing (scheme list) and (srfi 1), which must export car and cadr.  The bindings for R7RS libraries should be required to be the same.

I fully agree with this. However, R7RS-small is too much underspecified to make this work well in a portable manner: When I take the reference implementation of (srfi 1), which imports (scheme base) and re-exports the binding to, say, car, and a program imports (srfi 1) and (scheme base), it is not guaranteed that the bindings of car as exported by (srfi 1) and (scheme base), respectively, refer to the same locations because R7RS-small seems to make no guarantee that (scheme base) is loaded only once. The binding of car as exported by (srfi 1) may stem from a different loading than the binding as exported by the (scheme base) directly imported from the program.

There's no problem for the small language here, since importing different bindings under the same name "is an error".  Thus a hypothetical implementation allowing multiple instances of the same library at runtime would be required to resolve this error sensibly, choosing one of the bindings.

Which is not to say a more precise specification wouldn't be helpful for the large language.

--

Alex

[Marc Nieper-Wißkirchen]

There's no problem for the small language here, since importing different bindings under the same name "is an error".  Thus a hypothetical implementation allowing multiple instances of the same library at runtime would be required to resolve this error sensibly, choosing one of the bindings.

Is it so? The way I read the report, it is responsibility of the user not to import the same identifier with different bindings.The wording "it is an error" is not used in the sense of "must" (as an RFC keyword), which describes responsibilities of the implementation; e.g. we would rather say ’+’ must return the sum of its arguments than say that it is an error for ‘+’ not to return the sum of its argument.

The following example is an error (for which the user is responsible):

;; Library definitions
(define-library (foo) (export x) (import (scheme base)) (begin (define x 1)))
(define-library (bar) (export x) (import (scheme base)) (begin (define x 2)))
;; Program
(import (foo)) (import (bar)) ...

In analogy, the following is not guaranteed not to be an error:

;; Library definitions
(define-library (srfi 1) (export car ...) (import (scheme base)) (begin ...))
;; Program
(import (scheme base)) (import (srfi 1)) ...

However, for any sensible implementation of R7RS-small, it should not be an error.

--

Marc

[Alex Shinn]

Yes, what you say is exactly correct.  Moreover, if R7RS-large were to include a requirement to the effect that importing (scheme base), (scheme list) and (srfi 1) could be done without any conflicts, this would effectively require R7RS-large implementations to be sensible without saying anything about the underlying multiple library instance ambiguity.

[Marc Nieper-Wißkirchen]

Alex Shinn <alex...@gmail.com> schrieb am Di., 4. Juli 2017 um 11:14 Uhr:

Yes, what you say is exactly correct.  Moreover, if R7RS-large were to include a requirement to the effect that importing (scheme base), (scheme list) and (srfi 1) could be done without any conflicts, this would effectively require R7RS-large implementations to be sensible without saying anything about the underlying multiple library instance ambiguity.

Any such requirement for R7RS-large would also have to cover the case of user-provided libraries. E.g., the following should not be an error:

;; Library definitions

(define-library (extended-list-library)

  (import (scheme list) (scheme base))

  (export car ... extended-car ...)

  (begin ...))

;; Program

(import (scheme base) (extended-list-library)) ...

We also want the following to work in any case:

;; Library definitions

(define-library (gadgets)

  (import (scheme base))

  (export (make-gadget gadget? gadget-field gadget-set-field!)

  (begin

    (define-record-type <gadget>

      (make-gadget field)

      gadget?

      (gadget gadget-field gadget-set-field!))))

(define-library (frobnicator)

  (import (scheme base) (gadget))

  (export frobnicate-gadget!)

  (begin

    (define (frobnicate-gadget! gadget)

      (gadget-set-field! (+ 1 (gadget-field gadget))))))

(define-library (gadget-source)

  (import (scheme base) (gadget))

  (export a-gadget)

  (begin

    (define a-gadget (make-gadget 0))))

;; Program

(import (gadget-source) (frobnicator))

(frobnicate-gadget! a-gadget)

So, any requirement we add to the module system of R7RS-small should also be able cover this case. (Without, even implementations in the form of user-provided libraries of such simple concepts as the boxes of SRFI 111 are not possible in a portable way.)

-- Marc

On Tue, Jul 4, 2017 at 5:32 PM, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

There's no problem for the small language here, since importing different bindings under the same name "is an error".  Thus a hypothetical implementation allowing multiple instances of the same library at runtime would be required to resolve this error sensibly, choosing one of the bindings.

Is it so? The way I read the report, it is responsibility of the user not to import the same identifier with different bindings.The wording "it is an error" is not used in the sense of "must" (as an RFC keyword), which describes responsibilities of the implementation; e.g. we would rather say ’+’ must return the sum of its arguments than say that it is an error for ‘+’ not to return the sum of its argument.

The following example is an error (for which the user is responsible):

;; Library definitions
(define-library (foo) (export x) (import (scheme base)) (begin (define x 1)))
(define-library (bar) (export x) (import (scheme base)) (begin (define x 2)))
;; Program
(import (foo)) (import (bar)) ...

In analogy, the following is not guaranteed not to be an error:

;; Library definitions
(define-library (srfi 1) (export car ...) (import (scheme base)) (begin ...))
;; Program
(import (scheme base)) (import (srfi 1)) ...

However, for any sensible implementation of R7RS-small, it should not be an error.

--

Marc

--
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.

For more options, visit https://groups.google.com/d/optout.

--
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.

[John Cowan]

On Thu, Jun 29, 2017 at 8:59 AM, Will Clinger <cesu...@gmail.com> wrote:

True.  OTOH, if the string-hash and string-ci-hash exported by (scheme comparator) were the same as the deprecated versions exported by (scheme hash-table), they too would be deprecated.  I prefer to confine the deprecation to identifiers exported by a single library.

This puzzled me, so I didn't reply to it until now.  It seems that you understand deprecation to be a property of a *procedure*, whereas I understand it to be a property of an *export*.  Thus a single binding could be deprecated in one library and not deprecated in the other.  Unfortunately, there is at present no portable way to mark an exported identifier as deprecated. 

If there were, however, then when importing a binding from more than one library, it should provoke a deprecation warning only if it was deprecated in all of the libraries.

-- 

John Cowan          http://vrici.lojban.org/~cowan        co...@ccil.org

If [Tim Berners-Lee] has seen farther than others,

        it is because he is standing on a stack of dwarves.  --Mike Champion

[Alex Shinn]

On Tue, Jul 4, 2017 at 7:04 PM, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

So, any requirement we add to the module system of R7RS-small should also be able cover this case. (Without, even implementations in the form of user-provided libraries of such simple concepts as the boxes of SRFI 111 are not possible in a portable way.)

We're discussing new requirements to the R7RS-large language.

R7RS-small is done.  It is deliberately underspecified in many respects,

in the spirit of the R5RS and in the hopes of being an all-encompassing

and long-lasting specification.  Scheme has been around for over 40

years, and has a sort of timelessness about it by which I expect it to be

around another 60.  I have R7RS library wrappers around 30-year-old

Scheme code which don't even require any modification - just the external

library declaration file.  Given that, I can write my own code now confident

that it will run unmodified on any future Scheme implementation that

supports R7RS-small, an extremely easy target, at least to the extent

that makes sense given the implementation's limitations and experimental

features.

We had to specify some things.  Maybe this should have been, though

there were no proposals forthcoming at the time and I honestly can't

imagine one that would have been accepted.  Regardless, it's done,

and I can assure you anything you propose could be debated, so it's

very far from an errata.  It's perfectly reasonable, for example, to

consider an implementation where bindings imported via separate

libraries are not the same, but conflicting imports are resolved by

comparing the underlying code for equivalence.  This would allow for

plugging in a 3rd-party definition of (srfi 1) without breaking your

existing programs.

If you want to propose changes for the large language, by all means do so.

It's an ongoing process, and we want all the help we can get.  You seem to

disagree with the concept and charter of the small language, which is fine -

that's why the large language exists.

-- 

Alex

[John Cowan]

On Wed, Jul 5, 2017 at 11:10 AM, Alex Shinn <alex...@gmail.com> wrote:

On Tue, Jul 4, 2017 at 7:04 PM, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

So, any requirement we add to the module system of R7RS-small should also be able cover this case.

We're discussing new requirements to the R7RS-large language.

Indeed we are, one of which is how, if at all, to tighten the restrictions placed by the small language on the module system.  That's what Marc is addressing.

 

 This would allow for

plugging in a 3rd-party definition of (srfi 1) without breaking your

existing programs.

In any case, I think it is not too much to demand that *any* R7RS-compatible implementation of (srfi 1) get car by import from (scheme base) and, more to the point, cdddr by import from (scheme cxr), or both of them from some underlying library that also provides them to the standard libraries.

If you want to propose changes for the large language, by all means do so.

It's an ongoing process, and we want all the help we can get.

Marc is already massively contributing.  Please don't alienate him.

 

-- 

John Cowan          http://vrici.lojban.org/~cowan        co...@ccil.org

Any day you [see] all five woodpeckers is a good day.  --Elliotte Rusty Harold

[Alex Shinn]

On Thu, Jul 6, 2017 at 12:19 AM, John Cowan <co...@ccil.org> wrote:

Marc is already massively contributing.  Please don't alienate him.

No alienation was intended, quite the contrary, and I'm thankful

of his contributions.  He had proposed an errata to R7RS-small,

and I wanted to firmly reject shoe-horning any broad semantic

changes into errata, while encouraging the same changes to

be applied to the large language.

-- 

Alex

[Marc Nieper-Wißkirchen]

It is deliberately underspecified in many respects,

in the spirit of the R5RS and in the hopes of being an all-encompassing

and long-lasting specification.  Scheme has been around for over 40

years, and has a sort of timelessness about it by which I expect it to be

around another 60.  I have R7RS library wrappers around 30-year-old

Scheme code which don't even require any modification - just the external

library declaration file.  Given that, I can write my own code now confident

that it will run unmodified on any future Scheme implementation that

supports R7RS-small, an extremely easy target, at least to the extent

that makes sense given the implementation's limitations and experimental

features.

I agree with you on these merits of R7RS (and the previous standards R4RS and R5RS).

The particular underspecification of the module system of R7RS-small we are discussing, however, will lead people to write huge amounts of code for which their is no guarantee that it will run unmodified on any future R7RS-small implementation. The problem is not so much that R7RS-small is underspecified; the problem is that people don't expect this particular underspecification and wrtie code under some extra assumptions.

The sample implementations of SRFI 113 (or SRFI 125 oder SRFI 146), which claim R7RS-small compatibilty, make the assumptions that the comparator bindings from SRFI 128 imported by them is the same as the comparator bindings from SRFI 128 imported by the user code, which wants to call the procedures of one these SRFIs 113, 125, or 146.

By R7RS-small as written, Scheme implementations are possible for which these "R7RS-compatible" sample implementation are useless (and for which no portable implementation of one these SRFIs is possible). If some future R7RS-small implementation takes all these liberties, we will see lots of old code that won't work anymore.

 

If you want to propose changes for the large language, by all means do so.

It's an ongoing process, and we want all the help we can get.  You seem to

disagree with the concept and charter of the small language, which is fine -

that's why the large language exists.

Actually, I don't think that I disagree with the concept and charter of the small language. As I once said elsewhere, the report is piece of beauty that hasn't been matched by any other language specification I have seen so far. I just want to say the following: It was part of the charter to describe a module system. R7RS-small certainly achieved a goal as we now have a widely accepted module system. The module system of R7RS-small solved the problem of separation of namespaces and gave Scheme users a way to set up the initial top-level environment (of a body or library).

The specification of the module system, however, seemed to have stopped half-way. What it didn't solve is the interoperability between libraries, which, I think, is something a module system should cover as well. (Underlined by the fact that people writing Scheme code *think* that R7RS-small does cover it.)

-- 

Marc

[Marc Nieper-Wißkirchen]

I was in no way offended. Whether we can make minor corrections to the module system in R7RS-small or io R7RS-large or in R8RS depends on agreement. I just would like to see some resolution somewhere so that, for example, SRFI contributors know how to write portable code that will also run on future implementations.

A minor change that would be helpful, for example, would be the suggestion Alex made earlier:

There's no problem for the small language here, since importing different bindings under the same name "is an error".  Thus a hypothetical implementation allowing multiple instances of the same library at runtime would be required to resolve this error sensibly, choosing one of the bindings.

If we knew that R7RS-small implementations resolved this "error", what the sample implementation of SRFI 113 (sets and bags), for example, could do would be to import and re-export "comparator?", specifying the comparator-type, from SRFI 128. A program importing SRFI 128 (comparators) and SRFI 113 will then import the identifier "comparator?" twice. As Alex proposes, an implementation will have to chose the bindings of one of hypothetically multiple loads of SRFI 128.

This would solve the problem: The location of comparator? as imported from SRFI 128 and SRFI 113 will then have to come from one loading of SRFI 128, say Load1. So the library body of SRFI 113 will see the same comparator? as the main program. But R7RS-small specifies that loading multiple identifiers from the same library have to come from one loading, SRFI 113 will import all identifiers of SRFI 128 from the same Load1, as does the top-level program.

What do you think about this argument?

Marc

[Alex Shinn]

On Thu, Jul 6, 2017 at 1:41 AM, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

A minor change that would be helpful, for example, would be the suggestion Alex made earlier:

There's no problem for the small language here, since importing different bindings under the same name "is an error".  Thus a hypothetical implementation allowing multiple instances of the same library at runtime would be required to resolve this error sensibly, choosing one of the bindings.

If we knew that R7RS-small implementations resolved this "error", what the sample implementation of SRFI 113 (sets and bags), for example, could do would be to import and re-export "comparator?", specifying the comparator-type, from SRFI 128. A program importing SRFI 128 (comparators) and SRFI 113 will then import the identifier "comparator?" twice. As Alex proposes, an implementation will have to chose the bindings of one of hypothetically multiple loads of SRFI 128.

This would solve the problem: The location of comparator? as imported from SRFI 128 and SRFI 113 will then have to come from one loading of SRFI 128, say Load1. So the library body of SRFI 113 will see the same comparator? as the main program. But R7RS-small specifies that loading multiple identifiers from the same library have to come from one loading, SRFI 113 will import all identifiers of SRFI 128 from the same Load1, as does the top-level program.

This sounds reasonable to me, though I'd need to see the exact proposed wording.

I also realize why jumping to errata in the small language seems appealing, since

we haven't provided anywhere to collect such changes in the large language (short

or writing a SRFI).  We should do so.

-- 

Alex

[Marc Nieper-Wißkirchen]

Alex Shinn <alex...@gmail.com> schrieb am Do., 6. Juli 2017 um 15:41 Uhr:

I also realize why jumping to errata in the small language seems appealing, since

we haven't provided anywhere to collect such changes in the large language (short

or writing a SRFI).  We should do so.

Would it be possible to revivify the bug tracker/the ticket system used by WG 1?

Using this, we could probably sort any upcoming issues in one of the following categories:

0) Already in R7RS-small, not really an issue.

1) Really an erratum for R7RS-small.

2) For R7RS-large.

3) Should be in a next revision of the R7RS-small, i.e. R8RS.

4) Should be in the next iteration of IEEE-Scheme (should it be based on R7RS-small + Errata + Uncontroversial things).

5) Won't receive support by the majority of important implementations.

 
--

Marc

[Alex Shinn]

On Thu, Jul 6, 2017 at 11:00 PM, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

Alex Shinn <alex...@gmail.com> schrieb am Do., 6. Juli 2017 um 15:41 Uhr:

I also realize why jumping to errata in the small language seems appealing, since

we haven't provided anywhere to collect such changes in the large language (short

or writing a SRFI).  We should do so.

Would it be possible to revivify the bug tracker/the ticket system used by WG 1?

The ticket system is still open, I think from the beginning it was meant for both WGs.

Using this, we could probably sort any upcoming issues in one of the following categories:

0) Already in R7RS-small, not really an issue.

1) Really an erratum for R7RS-small.

2) For R7RS-large.

3) Should be in a next revision of the R7RS-small, i.e. R8RS.

4) Should be in the next iteration of IEEE-Scheme (should it be based on R7RS-small + Errata + Uncontroversial things).

5) Won't receive support by the majority of important implementations.

 
--

Marc

--

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-wg2+unsub...@googlegroups.com.

[Will Clinger]

John Cowan quoting me:

True.  OTOH, if the string-hash and string-ci-hash exported by (scheme comparator) were the same as the deprecated versions exported by (scheme hash-table), they too would be deprecated.  I prefer to confine the deprecation to identifiers exported by a single library.

This puzzled me, so I didn't reply to it until now.  It seems that you understand deprecation to be a property of a *procedure*, whereas I understand it to be a property of an *export*.  Thus a single binding could be deprecated in one library and not deprecated in the other.  Unfortunately, there is at present no portable way to mark an exported identifier as deprecated.

I understand deprecation to be a matter of documentation and culture,
not something that can be tested at compile time or run time, so there
are no portability issues here.

(More generally, I distinguish between deprecation by R7RS Red Edition,
by SRFIs on which R7RS Red Edition is based, and deprecation by
various implementations such as Larceny.  With regard to the specific
items we're discussing here, however, that distinction doesn't matter
because the R7RS Red Edition incorporates the SRFI deprecation by
reference, and the SRFI deprecation is so explicit that it's somewhat
redundant for Larceny and other implementations to be repeating it in
their own documentation, although I do believe such repetition assists
users of R7RS Red Edition.)

If there were, however, then when importing a binding from more than one library, it should provoke a deprecation warning only if it was deprecated in all of the libraries.

Please note that the deprecated string-hash and string-ci-hash of the
(scheme hash-table) and (srfi 125) libraries are clearly distinct from
the string-hash and string-ci-hash of (srfi 128).  That is obvious because
their specifications in SRFI 128 say they accept exactly one argument,
whereas their specifications in SRFI 125 say they *must* accept either
one or two arguments.  SRFI 125 says quite explicitly that those two
identifiers/procedures/whatever are "incompatible with the procedure
of the same name exported by SRFI 128 and SRFI 126.

Will

[John Cowan]

On Thu, Jul 13, 2017 at 4:52 PM, Will Clinger <cesu...@gmail.com> wrote:

That is obvious because
their specifications in SRFI 128 say they accept exactly one argument,

That is not my reading of SRFI 128, based on the rules promulgated in R5RS and R7RS.  R7RS section 1.3.2 says:

For example, it is an error for a procedure to be passed an argument of a type that the procedure is not explicitly specified to handle, even though such domain errors are seldom mentioned in this report. Implementations may signal an error, extend a procedure’s domain of definition to include such arguments, or fail catastrophically.

R5RS is similar.  I understand these requirements to mean that an implementation may accept additional arguments as well as known arguments of additional types, both of which would count as "extending the domain of definition."  Therefore, saying that a procedure accepts one argument does not require that it fail if invoked with two arguments, merely that the user cannot count on what will happen.

SRFI 125 says quite explicitly that those two
identifiers/procedures/whatever are "incompatible with the procedure
of the same name exported by SRFI 128 and SRFI 126.

I believe these statements are obiter dictum and not binding on implementors.  A SFRI cannot say authoritatively what another SRFI does or does not require, even when the same person wrote both of them.

-- 

 John Cowan          http://vrici.lojban.org/~cowan        co...@ccil.org

He made the Legislature meet at one-horse tank-towns out in the alfalfa

belt, so that hardly nobody could get there and most of the leaders

would stay home and let him go to work and do things as he pleased.

    --H.L. Mencken's translation of the Declaration of Independence

[Marc Nieper-Wißkirchen]

Am Sa., 27. Aug. 2016 um 06:16 Uhr schrieb John Cowan <johnw...@gmail.com>:

> There is one exception to this: SRFI 101, where the names intentionally collide with names in (scheme base) or (scheme cxr). I propose that this conflict be dealt with as follows:
>
> make-list to become make-rlist
> random-access-list->linear-access-list to become rlist->list
> linear-access-list->random-access-list to become list->rlist
> all other identifiers to be prefixed with "r" (rcons, rpair?, rcar, rmap, etc.)

There are one special form and one procedure in SRFI 101, which
doesn't solely work on random access lists, namely `quote` and
`equal?`, which don't seem to be covered well by the above renaming.
(I'm sorry for reporting this not earlier, but I didn't have the time
to look into it.)

(1) Is the quote syntax, which is defined by SRFI 101, being renamed
to `rquote`? How many implementations implement this properly? In the
context of R7RS, which allows shared and circular structure in
constants, SRFI 101's quote may need to be restricted to those
constants where the shared or circular structure does not extend to
pairs. The SRFI 116/(scheme ipair) counterpart is `iq' (for which
shared and circular structure would, in principle, be no problem). For
consistency and ease of use, it would at least make sense to have the
name `rq'.

(2) Renaming the `equal?' to `requal?', which only differs from
`equal?' that it can also compare random access lists, doesn't make
much sense, does it?. In the spirit of the other data structure
libraries voted into R7RS-large, it makes much more sense to add a
procedure like `rlist=', which is similar to `ilist='. And shouldn't
the SRFI 116-post finalization note about `equal?` apply to SRFI 101
as well?

P.S.: SRFI 116's sample implementation of `iq' is also not fully satisfactory:

(define (f) (iq (42)))

(eq? (f) (f)) ;=> ???

This should return #t if `iq' is analogous to `quote' as advertised
(the same holds for `rquote'), but with the sample implementation, it
doesn't.