RE: default declarations
It's arguably a bug in ghci -- but it's not quite clear what the right answer is. Suppose you are in the top level scope of two modules with differing default declarations. So GHCi uses the default default for the top level, always. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of Daniel Fischer | Sent: 06 August 2006 01:11 | To: GHC Users | Subject: default declarations | | Hi, | | apparently ghci doesn't take default declarations into account. | Inspired by a question on the hugs-users list I wrote | | module BoolNum where | | default (Bool, Rational) | | instance Num Bool where | (+) = (/=) | (-) = (/=) | (*) = () | negate x = x | abs x = x | signum x = x | fromInteger = odd | | | and in hugs, as expected I get | BoolNum 1 | True | | but in ghci, it's | *BoolNum 1 | 1, | | no defaulting apparently takes pkace. | | Why? | | Bug or feature ? | | Cheers, Daniel | -- | | In My Egotistical Opinion, most people's C programs should be | indented six feet downward and covered with dirt. | -- Blair P. Houghton | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Default declarations
Sven, You've already heard from nhc, hbc, and ghc, so here's the perspective from Hugs-land to complete your set. | What is the rationale for the second condition, i.e. why is no | defaulting done when a user-defined class is involved? Example: Defaulting is one of those places where Haskell makes an uncomfortable compromise between theory and practice. From a theoretical standpoint (e.g., providing a coherent semantics for programs using type classes), there is no justification at all for defaulting. It is a wart in the language design that lets a compiler make choices---and significant ones too, because the can change the semantics---without direct involvement from the programmer. But, in practice, the overloading of numeric literals makes it hard to get by without some defaults around. This is especially true in an interactive environment like Hugs, where people expect to be able to type in 1+1 and get 2, instead of some bizarre error message about unresolved overloading. So the rules for defaulting were designed to try and limit the number of times that defaulting would be used, but still allow it to kick in for the most common 1+1-style cases. You could drop the restriction that you've mentioned. You could drop the first condition too that requires at least one numeric class. This wouldn't fundamentally break anything. It would just mean that the defaulting mechanism kicks in more frequently, quietly making more decisions about the semantics that it assigns to your programs. Note that the compilers have to do extra work to check these conditions; it would be easy just to skip those checks if you wanted the more liberal policy. One day, there might be a better alternative to defaulting that gives programmers much more control, and isn't just restricted to numeric types (anyone for default monads?). In the meantime, I prefer to use a compiler that enforces the checks specified in the Haskell report, and so limits the scope for defaulting in my programs. It's true that, once in a while, I have to work a little harder to specify which instance is intended. But I'm also grateful for the opportunity that it gives me to participate more fully in choosing the intended semantics for my program. All the best, Mark
Re: Default declarations
Sven Panne wrote: The Haskell 98 report, section 4.3.4 states: [...] In situations where an ambiguous type is discovered, an ambiguous type variable is defaultable if at least one of its classes is a numeric class (that is, Num or a subclass of Num) and if all of its classes are defined in the Prelude or a standard library [...] What is the rationale for the second condition, i.e. why is no defaulting done when a user-defined class is involved? When no good reason for this restriction exists, it should be removed IMHO. This only extends the set of programs which can be compiled, and existing programs don't change their meaning. You will be pleased to hear that neither hbc nor nhc98 implement the second condition, so your example works fine with those compilers. Regards, Malcolm - [EMAIL PROTECTED] Department of Computer Science, University of York, YORK YO10 5DD, U.K.
