* Relationship between SRFI 165 and SRFI 159

SRFI 165 is both separating from SRFI 159 the part of SRFI 159's API
that deals with the environment monad into a reusable library as well
as extending this API in several ways and specifying its semantics
more precisely:

(1) Underlying the semantics of SRFI 159 is the environment monad. A
formatter of SRFI 159 is nothing but a monadic value of this monad.
[There is a slight error in the text of SRFI 159, which states that a
formatter is an environment  monad.]

SRFI 159 exports a number of procedures and macros that deal with the
underlying environment monad, for example, "fn", "with", "with!",
"each", etc. These procedures and macros provide (in principle) a very
general interface to an environment monad that can be used by code in
other contexts not related to formatting. For such code, we currently
have two options: (a) Such code can import (srfi 159 base) and only
use the general monadic procedures and macros. (b) Or, such code could
reinvent the wheel and have its own versions of "fn", "with", ... Both
options aren't optimal: Option (a) lacks modularity; the code would
depend on the formatting library while only being interested in the
non-formatting stuff in the library. Option (b) leads to the
repetition of work and, worse, would produce versions of "fn", "with",
... with different bindings than those exported by SRFI 159.

In fact, option (a) is not a completely viable option because SRFI
159's semantics applies implicit coercions to formatters through the
"displayed" procedure when the primitive monadic interface is used
with non-formatter values. Thus that part of SRFI 159 dealing solely
with the underlying environment is not as general as it could be.

Furthermore, SRFI 159 does not implement a general environment monad.
In the environment monad known from other functional languages,
monadic values can have arbitrary types; the monadic values of SRFI
159 (the formatters), however, have only the "void" type. A primitive
operation for monads is "bind" (">>=" in Haskell). SRFI 159 does not
provide this operation as for monadic values of type "void",
"sequence" (aka ">>") suffices. [SRFI's 159 "with" is more or less
(chibi monad environment)'s "bind", but that "bind" is not what is
usually called "bind" when talking about monads in computer science.)

The main raison d'être for SRFI 165 is to solve all these problems.
SRFI 165 bundles that part of SRFI 159's API that deals with the
environment into a reusable library on its own. Furthermore, the API
is completed to have the full power of environment monads for general
use cases. SRFI 159 would become a consumer of SRFI 165 (and
re-exporting bindings of "fn", "with", ...).

(2) Independently to the above, SRFI 165 changes what the runtime
representation of a state variable can be. In SRFI 159, state
variables are represented by symbols, making them easy to use but
potentially leading to naming conflicts. SRFI 39 (part of R7RS-small)
has chosen a different route: Its parameter objects are not
represented by symbols, but they have to be created explicitly with
"make-parameter" making them lexically scoped and allowing them to
take part in Scheme's macro hygiene.

SRFI 165's first draft follows SRFI 39 here: State variables are
represented by runtime values that have to be created explicitly via
"make-environment-variable". This leads to the following difference in
semantics: In SRFI 159's "(with ((var val) ...) ...)", "var" has to be
a <symbol> as is not evaluated. On the other hand, in SRFI 165's
"(with ((var val) ...) ...)", "var" has to be an expression that is
being evaluated to yield an environment variable. Thus SRFI 165's
semantics follows R7RS's parameterize and does not introduce new
semantics.

Due to this semantic change, SRFI 159 and SRFI 165 are currently in
conflict with each other despite what I wrote in (1). This conflict
has to be resolved in one or the other way:

(a) WG2 of R7RS-large decides that a version of SRFI 159 with hygienic
state variables (akin to parameter objects) would be an improvement.
In that case, SRFI 159 would be replaced by a slightly amended SRFI
XXX, which can then be based on SRFI 165 as currently written.

(b) WG2 retains the current semantics of SRFI 159. In that case, SRFI
165 has to be amended to allow not only allow runtime values created
by "make-environment-variable" to become state variables, but also raw
symbols. The semantic of SRFI 165's "(with ((var val) ...) ...)" could
then be as follows: The expression "(quasiquote var)" is evaluated to
either yield a symbol (value) or a value previously returned by
"make-environment-variable".

Resolution (a) has the advantage of being more in the spirit of the
rest of R7RS(-large) but requires to amend the Tangerine edition's
(scheme show) in a later edition (such a thing has happened before,
namely the switch from SRFI 121 to SRFI 158).

Resolution (b) has the advantage that it is backward compatible with
SRFI 159 while allowing hygienic state variables at the same time, but
the disadvantage that it may encourage the use of symbolic state
variables even in future code and that the semantics differ from prior
art, like "parameterize".

Marc

Am Do., 14. Feb. 2019 um 05:55 Uhr schrieb Arthur A. Gleckler
<xxxxxx@speechcode.com>:
>
> On Wed, Feb 13, 2019 at 8:20 PM Alex Shinn <xxxxxx@gmail.com> wrote:
>
>>
>> SRFI 159 is already written in terms of an environment monad with the same API as in this SRFI.
>> SRFI 165 just replaces the symbol semantics with parameter objects.
>
>
> I'm confused.  So someone using an implementation of SRFI 159 adapted to use SRFI 165 would use it in exactly the same way?  There must be some visible difference, or Marc wouldn't be proposing this change.  It seems like it would improve SRFI 165 if exactly how that worked were spelled out.  But maybe I'm more confused than I think.

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