Haskell is pure, so it cannot contain any linear-update procedures.
I meant that neither Scala nor Haskell has anything resembling either-swap.
If Eithers are used in the sense of value + flag (and not in the sense of
success vs failure), toggling the flag is a common operation in many
algorithms (think of red-black trees, etc.).
This does not generalize to the >2 case, however.
As the cost of exporting either-swap both under either-swap and
either-swap! is literally zero, I see little point in not including
it. :)
Per contra, I see no point in including a specialized variant of a specialized operation, whose likelihood of use is 1/epsilon^2.
I will check whether I am able to understand it. :)
If I cannot persuade you to change `maybe->list', could we at least
get an optional argument that defaults (if it really has to) to the
empty list, but which could be set to `#f' as well.
This is really a completely different protocol. I have called it the "multitruth" protocol, but a better name is needed.
This "most of the time" hardly does good to the beauty of Scheme.
The Maybe and Either objects are meant to be maximally beautiful, so the conversion between them and the other protocols is inevitably lossy; if not, there would be no need for Maybe/Either. See the introduction to the new "Protocol Conversions" section.
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.
I don't mind if you call it `maybe-cond'. I thought that `maybe-case'
is better because it is really about a finite number of cases and not
arbitrary conditions.
I'm continuing to exclude it from this SRFI. Maybe later (unless we get Nothing more).