thoughtful feedback on SRFI 241 on Reddit Arthur A. Gleckler (11 Nov 2022 23:40 UTC)
Re: thoughtful feedback on SRFI 241 on Reddit Lassi Kortela (12 Nov 2022 21:01 UTC)
Re: thoughtful feedback on SRFI 241 on Reddit Marc Nieper-Wißkirchen (12 Nov 2022 22:56 UTC)
Re: thoughtful feedback on SRFI 241 on Reddit Marc Nieper-Wißkirchen (13 Nov 2022 13:18 UTC)
Re: thoughtful feedback on SRFI 241 on Reddit John Cowan (13 Nov 2022 18:06 UTC)
Re: thoughtful feedback on SRFI 241 on Reddit Marc Nieper-Wißkirchen (13 Nov 2022 18:29 UTC)
Re: thoughtful feedback on SRFI 241 on Reddit Lassi Kortela (13 Nov 2022 19:40 UTC)
Re: thoughtful feedback on SRFI 241 on Reddit Marc Nieper-Wißkirchen (13 Nov 2022 20:19 UTC)

Re: thoughtful feedback on SRFI 241 on Reddit Marc Nieper-Wißkirchen 13 Nov 2022 18:29 UTC

Am So., 13. Nov. 2022 um 19:06 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Sun, Nov 13, 2022 at 8:18 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
>>
>> I will think about it; catamorphism is less generic than "implicit
>> recursion", so it should be clearer.
>
>
> That does not follow.  In natural-language semantics, "hyponym" is less generic than "narrower term", but saying that _raven_ is a hyponym of _bird_ is less clear than saying that _bird_ is a narrower equivalent of _raven_, unless the word _hyponym_ is already familiar to the reader.  A possible alternative to _catamorphism_ would be _generalized fold_, since many people have heard of folds but not catamorphisms (and similarly for unfolds and anamorphisms).

"Generalized fold" is better than "implicit recursion", I think.  If
no one objects, I will use this in the title.

>> That said, in my opinion this is not good Scheme code since record
>> types have been standardized.  Especially in a language with dynamic
>> typing, it is important to have strong runtime types; using general
>> lists to model trees, however, is an example of very weak typing.
>
>
> It's important to have record types, but it is not necessarily important to use them, depending on context.  Indeed, CL provides mechanisms for talking about lists and vectors of known size as if they were records: see <https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node175.html#SECTION002370000000000000000>.

I don't see the relevance in what CL provides.  In any case, I was
talking about what I think is good, modern Scheme code.

Dedicated types instead of general vectors (which, at least, don't
have the allocation cost of lists) also help the compiler.  Because of
the lack of static typing, the code it produces can be the better the
more specific types it can infer.

>> See my general comment above.  If you use let-match and lambda-match
>> regularly you are, at least in my opinion, probably not writing the
>> best Scheme code; Scheme has multiple values so where ML would need
>> records, for Scheme you would use apply and receive (SRFI 8).
>
>
> Or not, according to the same argument I gave above.  Multiple values are sometimes useful, but not always the most perspicuous approach: it would be false, for example, to claim that vectors are somehow "un-Schemey" because vector code could be systematically rewritten using multiple values.

Again, I don't see what it has to do with my argument. I never claimed
that one should always use multiple arguments or multiple values
(whatever this means).  But maybe, I misunderstood.