maybe-map etc. (sequence protocol)
Shiro Kawai
(04 Jun 2020 04:22 UTC)
|
||
Re: maybe-map etc. (sequence protocol) (no sender) (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.