Re: The monomorphism restriction and monomorphic pattern bindings

2008-04-30 Thread Ian Lynagh
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

2008-04-30 Thread Aaron Denney
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