Re: [Haskell-cafe] language proposal: ad-hoc overloading

On Sun, 2008-08-31 at 19:06 -0700, Ryan Ingram wrote:

On Sun, Aug 31, 2008 at 4:21 PM, Jonathan Cast wrote:

...

It seems as if you're proposing that

doubleSet :: Set.Set Int -> Set.Set Int doubleSet = map (*2)

doubleList :: [Int] -> [Int] doubleList :: map (*2)

work, but that you not be allowed to notice that the definitions are identical and substitute

double = map (*2)

for both definitions.

Yes, that's exactly what I am suggesting. This is especially important because Set cannot be made an instance of Functor because of the Ord restriction on the elements, so you can't generalize to fmap without redefining Functor as RestrictedFunctor or some such, which adds a ton of additional type-level programming that shouldn't be required for day-to-day work.

This concept of `day-to-day work' is a curious one. Haskell is not a mature language, and probably shouldn't ever be one. There will always be new discoveries in purely functional programming, and as the art advances, features like this ad-hoc overloading hack (and ACIO) will become obsolete and have to be thrown over-board. I'd rather (much rather!) people concerned with day-to-day programming for writing programs people actually use incorporate Haskell's features into other, more practical, languages (as those who *actually* care about such things are) rather than incorporating features from day-to-day production languages into Haskell.

I'm not against being able to use "double = map (*2)" generally, but the evidence I've seen says that the PL theory isn't there yet to do so without unacceptable performance penalties.

I don't believe in ``unacceptable performance penalties'' as a design criterion for Haskell. This is supposed to be a /research/ language.

(That definition violates the monomorphism restriction anyways).

So?

...

Sorry, but I use Haskell specifically because I do *not* want to use C++.

I don't think "a language I dislike also has this feature"

How about ``a language I dislike specifically (among other things) because of this `feature' also has this feature'? The great problem with C++ is that ad-hoc overloading allows operators to be defined in an ad-hoc way. In fact, C++ is now adding a feature similar to Haskell's type classes, in an attempt to reign ad-hoc overloading in. I don't thing Haskell should be trying to unreign ad-hoc overloading instead.

is a good argument against a feature. C++ also has named fields in records, and a standard I/O library. Should Haskell not have those either?

Standard I/O libraries are a bad idea, yes, and C++'s implementation of named fields has the same problem --- lack of principle types --- as its ad-hoc overloading. So sure, I'd oppose Haskell introducing either. jcc