作为Haskell中扩展类的原始类型？

Question

在Eiffel中，允许使用不从堆分配的扩展类 。 从开发人员的角度来看，很少有人会考虑自动将Int转换为Float。 我的问题是：为什么Haskell不选择类似的方法来建模Num。 具体来说，让我们考虑一下Int实例。 这是我提出问题的理由：

       [1..3] = [1,2,3]
       [1..3.5] = [1.0,2.0,3.0,4.0] -- rounds up

第二个列表是我没想到的，因为根据定义，任何两个整数之间都有无限的浮点数。 当然，一旦我们测试了序列，很明显它返回的是四舍五入的浮点数的底数。 需要进行这些转换的原因之一是，例如，我们可以计算一组整数的均值。

在Eiffel中，数字类型层次结构对程序员更友好，并且可以根据需要进行转换：例如，创建序列仍然可以是一组整数，这些整数会导致浮点均值。 这具有可读性的优势。

有没有理由在Haskell中未实现扩展类？任何引用都会有很大帮助。

@ony：关于并行策略的要点：使用原语时，我们不会面临同样的问题吗？ 手册的确不鼓励使用基元，这对我来说通常是有意义的，只要我们可以使用基元，就可能需要使用抽象类型。 我在尝试求平均值时面临的问题是缺少的分数整数实例，以及为什么5/3不能提升为浮点数而不是必须创建浮点数组来实现相同的结果。 为什么没有定义Int和Integer的小数实例的原因一定存在？ 那可以帮助我更好地理解基本原理。

@leftroundabout：问题不是关于扩展类本身，而是该功能可以提供的便利，尽管仅此功能不足以处理类型提升从int浮起的问题，例如我在对@ony的回复中提到的那样。 让我们以平均值的经典示例为例，尝试将其定义为

> [Int] :: Double
  let mean xs = sum xs / length xs (--not valid haskell code)
  [Int] :: Double
  let mean = sum xs / fromIntegral (length xs)

如果我不必调用fromIntegral来使均值函数起作用并且与缺少的Fractional Int联系在一起，我会很喜欢它。 尽管这种解释似乎很有意义，但我必须理解的是，如果我清楚我希望得到一个double并在我的类型签名中声明它还不足以进行适当的转换，那是不知道的吗？

Answer 1

[a..b]是enumFromTo ab简写， enumFromTo ab是Enum类型类的方法。 它开始于a和succ s，至第一次b超出。

[a,b..c]是简写enumFromThenTo abc类似于enumFromTo除了代替succ荷兰国际集团它把该差值ba各一次。 默认情况下，此差异是通过对Int的往返计算得出的，因此可以考虑或可以不考虑分数差异。 也就是说， Double运作符合您的预期

Prelude> [0.0, 0.5.. 10]
[0.0,0.5,1.0,1.5,2.0,2.5,3.0,3.5,4.0,4.5,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0]

[a..]是简写enumFrom a刚刚succ永恒。

[a,b..]是enumFromThen ab简写， enumFromThen ab永远加(ba) 。

Answer 2

至于行为，@ J.Abrahamson已经回答。 那就是enumFromThenTo的定义。

至于设计...实际上，GHC的Float#表示未装箱的类型（可以分配到任何位置，但是值很严格）。 由于Haskell是一种惰性语言，因此它假定大多数值最初都不是必需的，除非它们实际上是由带有严格参数的原语引用的。 考虑length [2..10] 。 在这种情况下，如果没有优化，Haskell甚至可以避免数字的生成，而只是建立一个列表（没有值）。 可能更有用的示例takeWhile (<100) [x*(x-1) | x <- [2..]] takeWhile (<100) [x*(x-1) | x <- [2..]] 。

但是，您不应该认为我们这里有开销，因为您使用的语言用大拇指将所有这些东西抽象化（严格的符号除外）。 Haskell编译器必须自己完成这项工作。 即，当编译器将能够告知列表的所有元素都将被引用（转换为常规形式）并且决定在一个返回堆栈中对其进行处理时，它可以在堆栈上分配该列表。

同样，通过这种方法，您可以通过使用多个CPU内核从代码中获得更多收益。 想象一下，使用策略，您的列表将在不同的内核上进行处理，因此它们应该在堆（而不是堆栈）上共享公共数据。