New draft (#4) of SRFI 189: Maybe and Either: optional container types Arthur A. Gleckler 02 Jun 2020 18:42 UTC
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
New draft (#5) of SRFI 189: Maybe and Either: optional container types Arthur A. Gleckler 02 Jun 2020 22:24 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 John Cowan 04 Jun 2020 22:50 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 06 Jun 2020 16:58 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 John Cowan 14 Jun 2020 00:06 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 14 Jun 2020 11:07 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types John Cowan 14 Jun 2020 15:58 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 John Cowan 14 Jun 2020 18:52 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 John Cowan 14 Jun 2020 20:30 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 John Cowan 14 Jun 2020 23:57 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 15 Jun 2020 06:22 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 15 Jun 2020 08:24 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types John Cowan 16 Jun 2020 18:47 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 16 Jun 2020 19:15 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 16 Jun 2020 19:17 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:56 UTC
Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Lassi Kortela 05 Jun 2020 16:12 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_