Am Mo., 15. Juni 2020 um 01:57 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

>> If you want to go with such a long word, `list/false' is not longer,
>> but maybe clearer. Why don't you like `->list*'?
>
>
> Because "*" has no fixed meaning in Lisp; it's like the use of ' or _ in Haskell as the equivalent of mathematical prime.  Prime is useful in local scope, but not very helpful at all in global scope.

let* is a good example, which exists at the global scope. The "*" may
not be the best choice, but it better conveys (while definitely not
optimally) the meaning than the suffix "multitruth".

We could also drop the naming scheme with "->" for these procedures
altogether (as the (co-)domain list + false does not have a name as a
Scheme type) for more freedom in naming.

Maybe others have better suggestions.

>> That's not unfolding, the anamorphism, which `unfold` is supposed to
>> be by SRFI 1. Anamorphisms have to exhaust their argument (as they
>> potentially produce streams).
>
>
> The 'unfold' function is indeed an anamorphism.  However, the unfold protocol need not meet all the requirements of an anamorphism, particularly when it comes to infinite generators.

"Particularly when it comes to infinite generators" doesn't seem to
make sense to me. "Unfold" is primarily about streams and not lists.

Anyway, excuse my frank words, but to me, it's just stupid not to
strive for regularity (as there are no other constraints that would
forbid us to) and, in all honesty, I don't understand why we have been
debating it so long. Why making a muddle of the semantics? If we have
a data type where we want an unfold-like procedure, that cannot meet
all requirements, forget it. But for the data types in this SRFI, it
just works. On the other hand, the way it is specified now, it
superficially looks like a duck, but it is not a duck.

Let me try to explain it differently: Let F be functor such that
streams (of whatever type) are terminal F-coalgebra. An object of an
F-coalgebra A is then given by the data "seed", "successor", and
"stop?". The "stream-unfold" procedure (from SRFI 41) then maps this
object to the corresponding stream. This is the true anamorphism. It
is clear that "stream-unfold" has to call "stop?" as long until it
returns #t.

All other "unfold" procedures can now be expressed in this
anamorphism: A regular "foo-unfold" is, in principle, nothing but the
composition of "stream-unfold" followed by "stream->foo". In general
"stream->foo" is only partially defined (it may yield the falsum in
Haskell's terminology). So, a "maybe-unfold" has to be, in principle,
"string-unfold" followed by "stream->maybe". This should leave no
doubt how "maybe-unfold" is to be implemented.

Marc