On Sun, 2008-08-31 at 19:06 -0700, Ryan Ingram wrote: > On Sun, Aug 31, 2008 at 4:21 PM, Jonathan Cast > <[EMAIL PROTECTED]> 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
