Thanks for the precisions and clarifications.

On Sun, Feb 24, 2019 at 5:03 PM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:

In which sense are SRFI 159 and SRFI 165 different in that regard? As the names in SRFI 159 are confined to the interior of "show", the names of SRFI 165 are confined to the interior of "run", regardless of what "confined" specifically means.

An excellent point, and I accept it.

Moreover, the names "forked", "fn", "with", "with!" appear in SRFI 165 exactly as in SRFI 159.

Because they do pollute the global namespace, then unless they are to be bound to exactly the same procedures or syntax procedures, they must use different names. If SRFI 159 bis is intended to use SRFI 165 explicitly, then I waive my objection.

The R7RS module system allows one to easily prefix imported names (e.g. to turn "run", "ask", "local", ... into "env-run", "env-ask", "env-local", ...),

True. But it has always been a rule that no such conflicts exist in the (scheme ...) libraries, except for the case of `bytevector-copy!` which was more or less forced on us.

while there is no way to strip prefixes generally.

I will be proposing that as an extension to `import` later in the R7RS-large process.

I agree that there have been some informal namespace conventions, but I have always seen them as originating from when basic algorithms (like "fold", "for-each", "find", etc.) are combined with concrete data types (like vectors, strings, hash-tables, mappings) and not as mandatory.

In fact, those names when unprefixed are specific to lists. That happened because SRFI 1 was the first SRFI written and finalized and has achieved quasi-standard status outside the RnRS process, and because lists are still informally the premier datatype of all Lisps.

This question is possibly not one that has to be answered by this SRFI. Should it become part of a future R7RS-large, WG 2 can always to decide that the "(scheme environment-monad)" is a library that exports all identifiers of SRFI 165, but with the prefix, say "env-".

We can and we have in the case of SRFI 101 (random-access immutable lists), where in fact all the names were changed, many but not all by prefixing "r". But I'd rather avoid it if I can.

In any case, I think that issue should be resolved consistently with respect to SRFI 165 and 159.

SRFI 159 is a fait accompli, though SRFI 159 bis (if it comes to fruition) is not. But see my note above about identical names being fine if the same underlying entity is named.

There remains, however, the point I raised earlier that the names in SRFI 159 are mostly less generic than in SRFI 165 (I'd like the more generic ones to be changed in SRFI 159 bis), and the further point that SRFI 159 has a special reason for brevity that SRFI 165 lacks: the need to compete with SRFI 48 for developer mindshare.

Thanks for pointing out your proposal to me. It looks very promising!

I am glad you think so.

I have grown up with the name "return" but I wouldn't mind the name "pure" instead.

Please change it, then.

You mean "default-computation", don't you?

Yes.

There may be a misunderstanding (and I should probably clarify that in the spec):

Yes, there is, and please do change it to something like the text below:

"default-computation" is not an unbound variable but an exported variable bound to a location holding an environment variable (in the sense of this SRFI, that is a value returned by "make-environment-variable"). The lexical binding of "default-computation" is supposed to stay the same all the time (indeed, as you say, it has to).

What the user is allowed to change is the environmental binding (in the sense of the environment monad) of "default-computation" during executing a computation.

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

It was impossible to inveigle

Georg Wilhelm Friedrich Hegel

Into offering the slightest apology

For his Phenomenology. --W. H. Auden, from "People" (1953)

(pedantic note: "inveigle" is actually pronunced to rhyme with "legal", not with "bagel", except for poetic license)