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_