Am Di., 18. Jan. 2022 um 22:23 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> On 2022-01-18 19:59 +0100, Marc Nieper-Wißkirchen wrote:
> > Haskell has no thunks (and needs no thunks), but Scheme has. Giving
> > them a special status in Scheme versus procedures with more than zero
> > arguments goes against basic principles. An even more basic principle
> > is that, if , the number 1, and not the number 0, should be given
> > special status in the domain of the non-negative integers.
>
> Theoretically I agree that we should not treat 0 as a special case.
> But nullary procedures *are* a special case, I argue, in Scheme
> practice.  They aren't isomorphic to constants, and we only tend to
> use them as a way to get a body expression evaluated with a certain
> continuation or in a certain environment.  Deriving a thunk from a
> positive-ary procedure is, I think, rarely useful for this reason.
> In Scheme programming, "nullary" isn't just the predecessor-ary of
> "unary", but a different beast.

For practical programming, yes, we don't need most such thunks that
would be generated; but the regularity that would be won could still
make reasoning about programs easier.

But I'm still thinking of how to make it both practical and regular.

> > ... that's why I have
> > been asking about compelling use cases that can't be solved with
> > standard Scheme, with cut, or with something like my "!".
>
> I've tried to explain why I find lambda* compelling (brevity of
> notation and ease of use, especially compared to cut, convenience in
> composition, etc.), and I know you haven't been similarly excited.  We
> can't talk about "compelling use cases" without reference to whom is
> feeling compelled.  Would you be willing to suggest the kind of
> example which you'd be happy to see?

If something is theoretically appealing (which lambda* isn't,
unfortunately, for the reasons discussed), its elegance may be enough
to make it part of Scheme.

If not, it should at least be helpful in practice. What I am looking
for is thus an example that can't be expressed similarly concisely
with what we already have, including cut and abbreviations to cut
(like !). Can you give me an example that is more than a toy example
and doesn't look like the direct translation of some, say, Haskell
demonstration code.

> > PS Another difference to Haskell is that Haskell has a static type
> > system that gives early errors. In Scheme, we don't have much ad-hoc
> > overloading so the dynamic type system can catch errors early. The
> > lambda* goes in a different direction.
>
> I'm also a bit concerned about the possibility that arity mistakes
> will be harder to catch.  But variadic procedures already cause plenty
> of confusion here; accidentally over-apply map or some other variadic
> form and you probably won't see the mistake until the program runs.

With Scheme, you usually only see errors when the program runs; that's
true, but especially because of that you should try hard so that the
error is raised early and near where you made it. Otherwise
(especially because of Scheme's inferior tooling environment compared
with mainstream languages), debugging can be a nightmare.

To give an example: One can argue that there shouldn't be length,
vector-length, and string-length but just a polymorphic length.
Barring questions of efficiency, this will make programs dealing with
vectors and strings shorter (because there is less to type), but it
will detect fewer type errors early. In a statically-typed language,
this is no problem. In a dynamically typed language, you should be
explicit and write what you mean. It also serves as a documentation.
As you only write code once, brevity is certainly not the most
important goal.

> The bottom line is that arity can be tricky to keep track of with
> variadic procedures, whether created with lambda* or not.

This suggests defining only very few procedures with lambda*.

Marc