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_