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 Wolfgang Corcoran-Mathe 14 Jun 2020 19:25 UTC

On 2020-06-14 18:08 +0200, Marc Nieper-Wißkirchen wrote:
> >> The `assume' is only for clarity; you can remove it without changing
> >> the semantics. The point is that `stop?' has to be called n + 1 times
> >> according to the `unfold' protocol when you generate something of
> >> length n.
> >>
> >
> > That makes sense only if `successor` is being called for its side effects
> > only.
> >
>
> Indeed. The same goes for `stop?'. If you want to implement the `unfold'
> protocol, you have to include this as well.  Otherwise, we better drop the
> unfold altogether.

Or perhaps it would be simplest to add that the result is unspecified
if the procedures passed to maybe / either-unfold have side-effects.

More generally, I'd like to understand how well-specified this
"unfold protocol" is.  I'm not aware of a SRFI defining "unfoldable"
types, or general requirements of -unfold procedures; are we just
following the general pattern of the unfolds of other SRFIs?  For
comparison, are there any other SRFIs which provide an unfold for
a non-sequence type, in which `successor' may not be called?  If
so, do they get the side-effecting case right?

If we're going to add phantom procedure calls in order to conform
to a protocol, it would be good to know that the protocol actually
exists!

Regards,

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"Therefore, 100 victories in 100 battles is not the most skillful.
Subduing the other's military without battle is the most skillful."
--_Sun Tzu_