[Haskell-cafe] language proposal: ad-hoc overloading
jonathanccast at fastmail.fm
Sun Aug 31 22:27:19 EDT 2008
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).
> > 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.
More information about the Haskell-Cafe