Email list hosting service & mailing list manager

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 Marc Nieper-Wißkirchen 14 Jun 2020 20:42 UTC

Am So., 14. Juni 2020 um 22:28 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:

> > That would be definitely wrong. See my example with `generator-unfold' I
> > gave to John.
>
> I wasn't able to find this example in the previous emails.

Has this post reached you by now?

> > If they don't get it right, we should correct them, not introduce the same
> > error here.
>
> This seems like a very long road to go down, one which does not end
> with unfold.  Very few non-mutating Scheme procedures which take
> procedure arguments specify when or how often those procedures will
> be called, from the perspective of calling those procedures for
> side-effects.  You can, of course, *infer* from the spec of say,
> map, that (map proc lis) will call proc (length lis) times, but
> that's, um, a side effect of the specification.  Making this sort of
> assumption concrete will mean changing a lot of specifications,
> I fear.

It very much depends on how careful a SRFI was written. SRFI 1 is
quite explicit, for example. This includes `unfold` in SRFI 1, from
which all other versions have been derived. (By the way, it is also
pretty clear on how often the PROC argument is called in `map`, and
specifies a bit more for `map-in-order`. R7RS-small is also very
explicit including the case of non-local control flow.

>
> Unfold expressions should satisfy certain theorems, but, if you
> expect that assumptions about side-effecting behavior drawn from
> SRFI 1 `unfold' will hold for FOO-unfold, I think you lose.
>
> --
> Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>
>
> "Not all programming languages have a way to write definitions, but
> most do.  Those that do not are for wimps."  --The Great Quux