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

[Jonathan Cast]

On Sun, 2008-08-31 at 19:06 -0700, Ryan Ingram wrote:
> On Sun, Aug 31, 2008 at 4:21 PM, Jonathan Cast
> <jonathanccast at fastmail.fm> 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