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)
|
> 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.