Email list hosting service & mailing list manager

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)
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 Marc Nieper-Wißkirchen (06 Jun 2020 16:59 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 Marc Nieper-Wißkirchen (14 Jun 2020 11:08 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 Marc Nieper-Wißkirchen (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 20:57 UTC)
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen (15 Jun 2020 06:23 UTC)
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen (15 Jun 2020 08:25 UTC)
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen (16 Jun 2020 19:16 UTC)
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen (16 Jun 2020 19:18 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:57 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 14 Jun 2020 20:57 UTC

Am So., 14. Juni 2020 um 22:30 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Sun, Jun 14, 2020 at 3:25 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>> What do you think of the names
>>
>> `just->list' and `right->list' instead? If given a Nothing or a Left, they will return #f as a special case. It is an error to call them on any other value.
>
>
> just->list would imply that it is an error to call it on a non-Just.  I'll stick with "multitruth" even though it's a rather oddball word.

If you want to go with such a long word, `list/false' is not longer,
but maybe clearer. Why don't you like `->list*'?

>> With the correct specification and implementation of `maybe-unfold' according to the protocol, a Scheme implementation can raise an error if
>>
>> (generator-unfold GEN maybe-unfold)
>>
>> is called on a generator of length 2 or more.
>
>
> That pretty much decides me on this issue.  I do *not* believe that it is an error to unfold into a fixed-size container from a generator that can deliver more values than the fixed size.  In particular, there is nothing wrong with unfolding an infinite generator into a fixed-size container.  The additional values available from the generator are simply never used for anything,

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).

> As for super-generators, they don't satisfy the generator protocol (which is specifically defined, unlike the unfold protocol), so I don't care how well or badly they work with generator-unfold.

I didn't say that "super-generators" have to work with
`generator-unfold`. They would have their own
`super-generator-unfold`. But for such a thing to work, one needs a
uniform unfold protocol.

And even without a specified unfold protocol, it is pretty much clear
what the correct definition is in the same way as it is clear that 1
shouldn't be considered a prime number.