Lightweight DTDs Marc Nieper-Wißkirchen (24 Nov 2021 07:31 UTC)
Time for generic generic functions? Lassi Kortela (24 Nov 2021 08:25 UTC)
Re: Time for generic generic functions? Marc Nieper-Wißkirchen (24 Nov 2021 08:43 UTC)
Re: Time for generic generic functions? Lassi Kortela (24 Nov 2021 09:08 UTC)
Re: Time for generic generic functions? Marc Nieper-Wißkirchen (24 Nov 2021 09:48 UTC)
(missing)
(missing)
Re: Time for generic generic functions? John Cowan (28 Nov 2021 04:11 UTC)
Re: Time for generic generic functions? John Cowan (26 Nov 2021 20:49 UTC)
Re: Time for generic generic functions? Marc Nieper-Wißkirchen (27 Nov 2021 08:26 UTC)
Re: Lightweight DTDs John Cowan (26 Nov 2021 22:21 UTC)

Re: Time for generic generic functions? Lassi Kortela 24 Nov 2021 09:08 UTC

> I have a very different view on this. If you know the type of your
> objects, write it down (in the form of a DTD, say).

"A programming language is low level when its programs require attention
to the irrelevant." Dynamic typing and static type inference were both
invented so we don't have to worry about these things.

> For a statically-typed language, it is no problem to let the compiler infer
> the type (this is how C++ ad-hoc overloading works), but for a
> dynamically-typed language like Scheme one really should be explicit so
> that errors are caught early.

That depends on what you want to do.

> If you know you have a list and only a list, invoke `length` and not,
> say, `generic-length`. It also helps documenting your code.

Common Lisp, Ruby, Python have a generic `length` and people don't
complain. They tend to complain that not enough other stuff is generic.

> The generic interface you propose is, no matter what, less efficient
> than the interface proposed by SRFI 225.

SRFI 225 is essentially one abstract base class (in C++/Java parlance).

But because we don't have a real class system, we ship the class name
around in every method call.

We lose both the efficiency and the expressiveness of statically typed
classes. We gain indirection for one task (among the dozens or hundreds
of tasks on which a Scheme programmer might want to indirect) at the
expense of a clumsy programming style that I haven't met in any other
language.

I just don't see how this tradeoff makes sense. Take one of the most
dynamic languages available and drag it a little bit toward static
typing, without truly getting any of the benefits of static typing.

> To conclude: If you think that a Scheme equivalent like
> `foo.filter(odd?).each(write)` is a good thing, add some kind of static
> type system to Scheme first.   Otherwise, the expression is hardly what
> you really want to express (because it is overly generic!).

The whole point of dynamic typing is not to pin things down.

Static Scheme would be a good thing, but should be a different language
from the ground up. Some ideas just don't fit together, and trying to
fit them in gets us the worst of both worlds.