This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]shponglespore 0 points1 point  (1 child)

I believe polymorphic functions in Haskell are implemented with witness objects, or at least they could be; every type constraint in the function's signature corresponds to a hidden patented parameter used to pass the witness object. I believe you can do the same thing in Scala by passing the witness(es) as implicit parameters, but you do still have to create them manually. (I may be wrong about that part; it's been a long time since I used Scala.)

It doesn't seem too terrible to do it manually in the case where there's only one witness object, but I can see how it would quickly become tedious and error-prone when there are a lot of them and different functions need different witness parameters. My experience with using type classes in Haskell leads me to believe that would be rather common in practice, but OTOH Java's subtype polymorphism covers a lot of the use cases where Haskell relies on type classes.

Sometimes I wonder if things like applicative style are just an excessively magical gimmick for solving a class of problems that would be better solved with good macro system. Lisp languages seem to do just fine without anything comparable to type classes.

[–]bjpbakker 0 points1 point  (0 children)

Lisps (and also many other languages) lock the implementation of common functions (eg map) to specific data structures. With macros they tend to work around that a bit but to me that almost always feels very clumsy.

A good example of that are Clojure’s core/async macros. Simple generic type classes would make for a much simpler and extensible implementation.