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
| 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? The rationale is that choosing a default has semantically important consequences, so (at least in the view of the people fixing this aspect of the design) shouldn't happen silently. After all, a user-defined class might have instances whose behaviour changes radically when the type changes. I don't expect you'll buy this argument but that's why it's there. It would be simple to give GHC a flag to change the rule. Indeed, you could do so yourself! Simon
Re: Default declarations
Malcolm Wallace wrote: > > 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. I thought it was greed that this restriction should go away already for the Haskell 1.3 report. Maybe someone forgot to edit it out? -- -- Lennart
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.
Default declarations
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? Example: default (Float) class Num a => Bar a where bar :: a -> String instance Bar Float where bar = const "Float" instance Bar Double where bar = const "Double" main :: IO () main = putStrLn (bar 123.456) This does not work, because the type of 123.456 must be an instance of Fractional (no problem) and Bar (problem!). More convincing, but longer examples can be constructed for geometric things like vectors, matrices, etc. which contain elements of a polymorphic numeric type. 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. Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
