New draft (#4) of SRFI 189: Maybe and Either: optional container types Arthur A. Gleckler 02 Jun 2020 18:42 UTC
Re: New draft (#4) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 02 Jun 2020 18:48 UTC
Re: New draft (#4) of SRFI 189: Maybe and Either: optional container types Wolfgang Corcoran-Mathe 02 Jun 2020 19:08 UTC
Re: New draft (#4) of SRFI 189: Maybe and Either: optional container types Wolfgang Corcoran-Mathe 02 Jun 2020 19:06 UTC
Re: New draft (#4) of SRFI 189: Maybe and Either: optional container types Wolfgang Corcoran-Mathe 02 Jun 2020 19:12 UTC
New draft (#5) of SRFI 189: Maybe and Either: optional container types Arthur A. Gleckler 02 Jun 2020 22:24 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 04 Jun 2020 10:26 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types John Cowan 04 Jun 2020 22:50 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 06 Jun 2020 16:58 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Wolfgang Corcoran-Mathe 07 Jun 2020 04:29 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 07 Jun 2020 10:28 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types John Cowan 14 Jun 2020 00:06 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 14 Jun 2020 11:07 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types John Cowan 14 Jun 2020 15:58 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 14 Jun 2020 16:08 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types John Cowan 14 Jun 2020 18:52 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 14 Jun 2020 19:25 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types John Cowan 14 Jun 2020 20:30 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 14 Jun 2020 20:57 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types John Cowan 14 Jun 2020 23:57 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 15 Jun 2020 06:22 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 15 Jun 2020 08:24 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types John Cowan 16 Jun 2020 18:47 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 16 Jun 2020 19:15 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 16 Jun 2020 19:17 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Wolfgang Corcoran-Mathe 17 Jun 2020 17:17 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Wolfgang Corcoran-Mathe 14 Jun 2020 19:25 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 14 Jun 2020 19:43 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Wolfgang Corcoran-Mathe 14 Jun 2020 20:28 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 14 Jun 2020 20:42 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Wolfgang Corcoran-Mathe 15 Jun 2020 13:13 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 16 Jun 2020 07:56 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Lassi Kortela 05 Jun 2020 16:12 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 06 Jun 2020 16:59 UTC

Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 15 Jun 2020 06:22 UTC

Am Mo., 15. Juni 2020 um 01:57 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

>> If you want to go with such a long word, `list/false' is not longer,
>> but maybe clearer. Why don't you like `->list*'?
>
>
> Because "*" has no fixed meaning in Lisp; it's like the use of ' or _ in Haskell as the equivalent of mathematical prime.  Prime is useful in local scope, but not very helpful at all in global scope.

let* is a good example, which exists at the global scope. The "*" may
not be the best choice, but it better conveys (while definitely not
optimally) the meaning than the suffix "multitruth".

We could also drop the naming scheme with "->" for these procedures
altogether (as the (co-)domain list + false does not have a name as a
Scheme type) for more freedom in naming.

Maybe others have better suggestions.

>> That's not unfolding, the anamorphism, which `unfold` is supposed to
>> be by SRFI 1. Anamorphisms have to exhaust their argument (as they
>> potentially produce streams).
>
>
> The 'unfold' function is indeed an anamorphism.  However, the unfold protocol need not meet all the requirements of an anamorphism, particularly when it comes to infinite generators.

"Particularly when it comes to infinite generators" doesn't seem to
make sense to me. "Unfold" is primarily about streams and not lists.

Anyway, excuse my frank words, but to me, it's just stupid not to
strive for regularity (as there are no other constraints that would
forbid us to) and, in all honesty, I don't understand why we have been
debating it so long. Why making a muddle of the semantics? If we have
a data type where we want an unfold-like procedure, that cannot meet
all requirements, forget it. But for the data types in this SRFI, it
just works. On the other hand, the way it is specified now, it
superficially looks like a duck, but it is not a duck.

Let me try to explain it differently: Let F be functor such that
streams (of whatever type) are terminal F-coalgebra. An object of an
F-coalgebra A is then given by the data "seed", "successor", and
"stop?". The "stream-unfold" procedure (from SRFI 41) then maps this
object to the corresponding stream. This is the true anamorphism. It
is clear that "stream-unfold" has to call "stop?" as long until it
returns #t.

All other "unfold" procedures can now be expressed in this
anamorphism: A regular "foo-unfold" is, in principle, nothing but the
composition of "stream-unfold" followed by "stream->foo". In general
"stream->foo" is only partially defined (it may yield the falsum in
Haskell's terminology). So, a "maybe-unfold" has to be, in principle,
"string-unfold" followed by "stream->maybe". This should leave no
doubt how "maybe-unfold" is to be implemented.

Marc