Thanks for chiming in, John.

Am So., 24. Feb. 2019 um 21:51 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

As chair of R7RS-large, and particularly if SRFI 165 is meant to be incorporated into R7RS-large (as I suppose), I would request that it stick to the informal namespace conventions of such SRFIs, and avoid names such as `run, ask, local, return, sequence, bind, forked, fn, with, with!`. Short names like this should be left to the user.

I didn't object to such names in SRFI 159 because even though they pollute the global namespace, they are effectively confined to the interior of `show`, and in any case are mostly names unlikely to be used by other libraries.

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. Moreover, the names "forked", "fn", "with", "with!" appear in SRFI 165 exactly as in SRFI 159.

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", ...), while there is no way to strip prefixes generally. In other words, it has some advantages if a library exports names without prefixes.

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.

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-". Alternatively, this SRFI could offer two interfaces, say (srfi 165) and (srfi 165 base), where the only difference is that (srfi 165) exports all identifiers with a prefix and (srfi 165 base) without.

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

Not so for SRFI 165, which is a specific monad. I expect there to be a general monad library eventually in R7RS-large, and even there I am not planning to use such short names (see https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/ContextsCowan.md for my current ideas).

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

As a personal matter, I think `return` misleading in an imperative language, and suggest the name `pure` instead. Although in Haskell this is used for class ApplicativeFunctor rather than Monad, they are defined the same way for monads in all recent versions of Haskell, and the use of a different name merely reflects Haskell's monomorphism (which Scheme shares) and its users' aversion to longer names (which Schemers mostly do not share).

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

====

I also strongly suggest that `current-computation` be made to hold a parameter object whose initial value is a procedure that raises an error, rather than a simple variable. This is not only more convenient, but necessary, because R7RS allows (and R6RS requires) that imported names not be redefinable.

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

There may be a misunderstanding (and I should probably clarify that in the spec): "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. For example, "show" of SRFI 159 could be implemented in terms of SRFI 165 as follows:

(define (show out . args)
(let ((fmt (each-in-list args)))
    (cond
     ((output-port? out)
      (%show out fmt))
     ((eq? #t out)
      (%show (current-output-port) fmt))
     ((eq? #f out)
      (let ((out (open-output-string)))
        (%show out fmt)
        (get-output-string out)))
     (else
      (assume #f)))))

(define (%show out fmt)
(run (sequence (with! (port out)
                        (col 0)
                        (row 0)
                        (width 78)
                        (radix 10)
                        (pad-char #\space)
                        (output output-default)
                        (string-width string-length)
                        (default-computation displayed)) ; XXXXX
                 fmt)))

Does this explanation solve that issue? Or did I misunderstand you?

Thanks,

Marc

--
John Cowan http://vrici.lojban.org/~cowan xxxxxx@ccil.org
"Make a case, man; you're full of naked assertions, just like Nietzsche."
"Oh, i suffer from that, too. But you know, naked assertions or GTFO."
--heard on #scheme, sorta