Am Mo., 25. Feb. 2019 um 01:01 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
> 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.

Indeed, this is intended. Code employing SRFI 159 bis shall be able to
use all of SRFI 165 as the underlying implementation of the
environment monad is supposed to be the same.

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

Great to hear.

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

Would a prefix "env-" be agreeable?

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

Of course, SRFI 165 could still export, say "with", as "env-with", and
SRFI 159 (bis) could import "env-with" from SRFI 165 and re-export it
as "with".

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

Names like "fn", "nl", "fl", "with", "with!", "each" will pose a
problem. They are quite generic (the latter even more), while at the
same time probably used often in formatter code.

That said, with a way to strip prefixes in library imports, it won't
be a problem if SRFI 159 bis exported all these names prefixed with,
say "formatter/".

Alex, the author of SRFI 159, has already stated that he is willing to
write a SRFI 159 bis if it clear that it won't be in vain.

>
>>
>> Thanks for pointing out your proposal to me. It looks very promising!
>
>
> I am glad you think so.

What you describe in that proposal is a way to turn a specific
implementation (like a list, vector, environment monad, etc.) into an
instance of a generic concept (functor, idiom, monad) so that generic
procedures can be applied.

I am wondering whether we should discuss an object system for
R7RS-large first so that your proposal can build on the provided
primitives/syntax of the general object system (reifying the concepts
"implementation", "instance", and "concept" from above; comparable to
C++ templates with C++20 concepts).

>
>>
>> I have grown up with the name "return" but I wouldn't mind the name "pure" instead.
>
>
> Please change it, then.

If there is no objection until then, it will have the new name in the
next draft.

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

And here, it has to rhyme with "Hegel", apparently a third way to
pronounce that word.

--
Prof. Dr. Marc Nieper-Wißkirchen

Universität Augsburg
Institut für Mathematik
Universitätsstraße 14
86159 Augsburg

Tel: 0821/598-2146
Fax: 0821/598-2090

E-Mail: xxxxxx@math.uni-augsburg.de
Web: www.math.uni-augsburg.de/alg/mitarbeiter/mnieper/