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