| > 1. Actually, I wouldn't even call that "default | definitions". These ARE | > definitions of sinh and cosh. | | Mathematically, yes. Numerically, no. Even if 'exp' is | implemented with high accuracy, the suggested defaults may | return a very inaccurate (in ulps) result. Take sinh near | zero. sinh(x) with x very close to 0 should return x. With | the above 'default' sinh(x) will return exactly 0 for a | relatively wide interval around 0, which is the wrong result | except for 0 itself. Indeed. The proposal is only to give "default declarations" in the class defn for sinh, cosh, and perhaps as Lennart suggests asinh, acosh, atanh. They give a reasonable first cut if you don't write definitions yourself. But you can overrride them at will. The only reason not to do this (which amounts to giving a default decl of "error") is if the default decl is so awful that it's badly misleading to provide it. Which doesn't look true in this case. I don't propose to change any of the actual instance declarations, because (as Lennart says) it's entirely possible that they have better numerical properties than the default declarations. Simon
On 15-Oct-2001, Simon Peyton-Jones <simonpj@microsoft.com> wrote:
The proposal is only to give "default declarations" in the class defn for sinh, cosh, and perhaps as Lennart suggests asinh, acosh, atanh. They give a reasonable first cut if you don't write definitions yourself. But you can overrride them at will. The only reason not to do this (which amounts to giving a default decl of "error") is if the default decl is so awful that it's badly misleading to provide it. Which doesn't look true in this case.
Not giving a default definition is *not* the same as giving a default definition that calls "error". It's significantly safer. The difference is that the former makes it much easier for compilers to issue warnings when you forget to define a class method in an instance declaration. With the latter, compilers can't issue such warnings without getting too many false positives. The whole idea of letting you omit method definitions for methods with no default and having calls to such methods be run-time errors is IMHO exceedingly odd in a supposedly strongly typed language, and IMHO ought to be reconsidered in the next major revision of Haskell. -- Fergus Henderson <fjh@cs.mu.oz.au> | "... it seems to me that 15 years of The University of Melbourne | email is plenty for one lifetime." WWW: <http://www.cs.mu.oz.au/~fjh> | -- Prof. Donald E. Knuth
On Tuesday 16 October 2001 07:29, Fergus Henderson wrote:
[...] The whole idea of letting you omit method definitions for methods with no default and having calls to such methods be run-time errors is IMHO exceedingly odd in a supposedly strongly typed language, and IMHO ought to be reconsidered in the next major revision of Haskell.
This is exactly what I think. Wolfgang
On Tuesday 16 October 2001 07:29, Fergus Henderson wrote:
[...] The whole idea of letting you omit method definitions for methods with no default and having calls to such methods be run-time errors is IMHO exceedingly odd in a supposedly strongly typed language, and IMHO ought to be reconsidered in the next major revision of Haskell.
This is exactly what I think.
I agree too, but being able to omit method definitions is sometimes useful -- would it be possible to make calls to those methods a /static/ error? I suspect this would be hard to do. -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk 31 Chalmers Road jf@cl.cam.ac.uk Cambridge CB1 3SZ +44 1223 570179 (after 14:00 only, please!)
Hi! Jon Fairbairn wrote:
I agree too, but being able to omit method definitions is sometimes useful -- would it be possible to make calls to those methods a /static/ error? I suspect this would be hard to do.
Yes, quite tricky. The problem is that the class constraints (in an inference algorithm or a semantics) only record that some method was used, not which one. And at the method invocation site it is not known which instance declaration the method will come from (that's the point of the Haskell class system, after all). There are two solutions that I can see: Annotate classes in class constraints with exactly which methods were used. Thus for the expression "x+y" the inference algorithm would record the constraint "Num{+} a" if x and y has type a in the type environment. Then if an instance declaration for type Wurble omitted +, that instance declaration would not allow us to simplify "Num{+} Wurble". The second possibility would be to use a separate dataflow analysis after dictionary conversion to find out if some incomplete dictionary could flow to a dangerous place. For compilers which use partial evaluation to eliminate overloading, this would be particularly easy. But I think that, given the stylized way dictionaries are inserted in the code, that this solution is viable in general. Cheers, /kff
participants (5)
-
Fergus Henderson -
Jon Fairbairn -
Karl-Filip Faxen -
Simon Peyton-Jones -
Wolfgang Jeltsch