I'm trying to figure out why this does not compile
我试图找出为什么这不编译
yell :: (Floating a) => a -> [Char]
yell x
| x > 10.0 = "Yelling"
| otherwise = "No Yell"
but this
yell :: (Floating a, Ord a) => a -> [Char]
yell x
| x > 10.0 = "Yelling"
| otherwise = "No Yell"
and this
yell :: (RealFloat a) => a -> [Char]
yell x
| x > 10.0 = "Yelling"
| otherwise = "No Yell"
do compile.
I know that Floating and Ord are typeclasses, but isn't every member of Floating also a member of Ord? And in the end, is RealFloat just a "inner join" of Floating and Ord?
我知道Floating和Ord是类型类,但并不是每个浮动的成员也是Ord的成员?最后,RealFloat只是Floating和Ord的“内部联接”吗?
2 个解决方案
#1
but isn't every member of
Floating
also a member ofOrd
?但浮动的每个成员都不是奥德的成员吗?
The obvious counterexample are complex numbers. Also, some types that give good Num
etc. instances don't allow equality or inequality comparisons at all, because they represent more than just a single number value, but e.g. a generic abstraction over function results of some number type. (That's why Eq
is not a superclass of Num
, though it used to be.)
显而易见的反例是复数。此外,一些提供良好Num等实例的类型根本不允许相等或不等式比较,因为它们不仅仅代表单个数字值,而且例如某种数字类型的函数结果的通用抽象。 (这就是为什么Eq不是Num的超类,虽然它曾经是。)
in the end, is
RealFloat
just a "inner join" ofFloating
andOrd
?最后,RealFloat只是Floating和Ord的“内部联接”吗?
Pretty much, though Real
, RealFrac
and RealFloat
actually contain a lot of very specific convenience methods – but I think you could implement them all (albeit much less efficiently) with just a (Floating a, Ord a)
constraint.
虽然Real,RealFrac和RealFloat实际上包含了许多非常具体的便利方法 - 但我认为你可以只用一个(浮动a,Ord a)约束来实现它们(尽管效率低得多)。
#2
Let's see definition of Floating
typeclass. I think it's just defined as something that guarantees that the following functions can be used with it:
我们来看看Floating类型类的定义。我认为它只是定义为保证以下功能可以使用的东西:
pi, exp, log, sin, cos, asin, acos, atan, sinh, cosh, asinh, acosh, atanh
pi,exp,log,sin,cos,asin,acos,atan,sinh,cosh,asinh,acosh,atanh
None of them requires its argument to be instance of Ord
, so it's not. On the other hand Real
is an instance of Ord
and so is RealFloat
.
他们都不要求它的论点是Ord的实例,所以事实并非如此。另一方面,Real是Ord的一个实例,RealFloat也是如此。
#1
but isn't every member of
Floating
also a member ofOrd
?但浮动的每个成员都不是奥德的成员吗?
The obvious counterexample are complex numbers. Also, some types that give good Num
etc. instances don't allow equality or inequality comparisons at all, because they represent more than just a single number value, but e.g. a generic abstraction over function results of some number type. (That's why Eq
is not a superclass of Num
, though it used to be.)
显而易见的反例是复数。此外,一些提供良好Num等实例的类型根本不允许相等或不等式比较,因为它们不仅仅代表单个数字值,而且例如某种数字类型的函数结果的通用抽象。 (这就是为什么Eq不是Num的超类,虽然它曾经是。)
in the end, is
RealFloat
just a "inner join" ofFloating
andOrd
?最后,RealFloat只是Floating和Ord的“内部联接”吗?
Pretty much, though Real
, RealFrac
and RealFloat
actually contain a lot of very specific convenience methods – but I think you could implement them all (albeit much less efficiently) with just a (Floating a, Ord a)
constraint.
虽然Real,RealFrac和RealFloat实际上包含了许多非常具体的便利方法 - 但我认为你可以只用一个(浮动a,Ord a)约束来实现它们(尽管效率低得多)。
#2
Let's see definition of Floating
typeclass. I think it's just defined as something that guarantees that the following functions can be used with it:
我们来看看Floating类型类的定义。我认为它只是定义为保证以下功能可以使用的东西:
pi, exp, log, sin, cos, asin, acos, atan, sinh, cosh, asinh, acosh, atanh
pi,exp,log,sin,cos,asin,acos,atan,sinh,cosh,asinh,acosh,atanh
None of them requires its argument to be instance of Ord
, so it's not. On the other hand Real
is an instance of Ord
and so is RealFloat
.
他们都不要求它的论点是Ord的实例,所以事实并非如此。另一方面,Real是Ord的一个实例,RealFloat也是如此。