Email list hosting service & mailing list manager

maybe-map etc. (sequence protocol) Shiro Kawai (04 Jun 2020 04:22 UTC)
Re: maybe-map etc. (sequence protocol) Marc Nieper-Wißkirchen (04 Jun 2020 07:52 UTC)
Re: maybe-map etc. (sequence protocol) Shiro Kawai (04 Jun 2020 08:20 UTC)
Re: maybe-map etc. (sequence protocol) John Cowan (04 Jun 2020 19:43 UTC)
Re: maybe-map etc. (sequence protocol) Lassi Kortela (05 Jun 2020 15:53 UTC)
Re: maybe-map etc. (sequence protocol) Wolfgang Corcoran-Mathe (05 Jun 2020 17:36 UTC)
(missing)
Re: maybe-map etc. (sequence protocol) Wolfgang Corcoran-Mathe (05 Jun 2020 17:58 UTC)

Re: maybe-map etc. (sequence protocol) Marc Nieper-Wißkirchen 04 Jun 2020 07:52 UTC

Am Do., 4. Juni 2020 um 06:22 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>
> Sorry for commenting in the last minute---I just started implementing it and finally took a closer look.
>
> I thought maybe-map would map proc to every value contained in maybe but realized it's more like the sense of fmap in Haskell Functor, correct?
>
> I do see the consistency, but I'm not sure the value of providing *-for-each, *-fold and *-unfold full-set of sequence protocol, as they are trivially implemented.   How much do we expect that Maybe and Either being used as a 0-or-1 length sequence?
>
> My concern is that *-map family has been used for n-length sequences, and our Maybe/Either has multiple values, it can be easily confused users expecting  srfi-189 *-map etc. are for mapping operations on each value it contains.

As we want that SRFI 189 will fit into a general monadic framework (I
guess that we will see more monads while R7RS-large takes shape), I am
very much in favor of leaving these procedures in SRFI 189, although
they are almost trivial for this type of monad.

I agree, though, that it may make sense to add a clarifying paragraph
at the beginning concerning multiple values, which makes it clear that
"multiple values" (which is not a first-class citizen in Scheme; but
see SRFI 195 for a reification) are abstractly not a sequence of
single values.  In Scheme, we do not have type signatures, which makes
some explanations wordier and harder to understand.  If we had
Haskell-like types, there would be a type `a' for each shape of
multiple values (in Scheme, the shape of a multiple value is
completely determined by the number of values; but see the Kernel
programming language, which allows trees if I remember correctly).

So, we have, for example, a Maybe type `Maybe a', which either stores
a "value" of shape/type `a' or a Nothing. If  `*' is the type
corresponding to a single value and `[*]' the type of lists of length
`a', `Maybe a' is not the same as `Maybe [*]'. As `a' is an abstract
type on this level, it simply does not make sense for the sequence
operations to traverse whatever may be stored in `a', so no confusion
can arise.