Re: The monomorphism restriction and monomorphic pattern bindings
On Wed, Apr 23, 2008 at 10:32:24AM -0700, Simon Marlow wrote: > The current proposal on the table for what to do about the monomorphism > restriction (henceforth MR) is > > * remove the MR entirely Just to be clear, are we talking only about Rule 1 of the MR? Rule 2 seems unavoidable, but it should probably say "entire group of mutually recursive modules" rather than "entire module". ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Meta-point: backward compatibility
On Thu, Apr 24, 2008 at 08:18:10PM +, Aaron Denney wrote: > And there is a lot that clearly isn't battle tested in a reasonable new > form, though the current practice is widely agreed upon to be broken. > Examples include all monads having fail, rather than only those in a > subclass, monad not being a subclass of functor, and the whole numeric > hierarchy issue (which I don't think can be properly designed unless we > know whether it's going to be FDs or ATs, though, of course, designing > it for either would provide valuable experience for the limitations > of both), I don't think any of these need involve multi-parameter type classes (we don't need vector spaces in the Prelude), but they're often presented as use cases for things like class aliases. Even then, the numeric hierarchy is probably easier to fix that the others: one can define a finer-grain hierarchy with the existing classes as a facade, and leave clients untouched. The change would be felt by the minority defining instances of numeric classes, but they are exactly the people who find the present hierarchy inadequate. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: The monomorphism restriction and monomorphic pattern bindings
On Wed, Apr 30, 2008 at 12:18:47PM +0100, Ross Paterson wrote: > On Wed, Apr 23, 2008 at 10:32:24AM -0700, Simon Marlow wrote: > > The current proposal on the table for what to do about the monomorphism > > restriction (henceforth MR) is > > > > * remove the MR entirely > > Just to be clear, are we talking only about Rule 1 of the MR? > > Rule 2 seems unavoidable, but it should probably say "entire group of > mutually recursive modules" rather than "entire module". Rule 2 Any monomorphic type variables that remain when type inference for an entire module is complete, are considered ambiguous, and are resolved to particular types using the defaulting rules. Sounds right to me. Although personally I think defaulting should be removed from the language (but left in the interactive environments), but that's another debate! Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Meta-point: backward compatibility
On 2008-04-30, Ross Paterson <[EMAIL PROTECTED]> wrote: > On Thu, Apr 24, 2008 at 08:18:10PM +, Aaron Denney wrote: >> And there is a lot that clearly isn't battle tested in a reasonable new >> form, though the current practice is widely agreed upon to be broken. >> Examples include all monads having fail, rather than only those in a >> subclass, monad not being a subclass of functor, and the whole numeric >> hierarchy issue (which I don't think can be properly designed unless we >> know whether it's going to be FDs or ATs, though, of course, designing >> it for either would provide valuable experience for the limitations >> of both), > > I don't think any of these need involve multi-parameter type classes > (we don't need vector spaces in the Prelude), but they're often presented > as use cases for things like class aliases. Even then, the numeric > hierarchy is probably easier to fix that the others: one can define a > finer-grain hierarchy with the existing classes as a facade, and leave > clients untouched. The change would be felt by the minority defining > instances of numeric classes, but they are exactly the people who find > the present hierarchy inadequate. Class aliases (or the ability to add superclasses) would certainly help in letting many of these things be more easily tested. I suppose we don't need vector spaces. Nor do we need rationals, complex numbers, or even arbitrarily large integers. Nevertheless, there is a huge benefit to having the interfaces for them there. -- Aaron Denney -><- ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
