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_