为元组特别保留不同的数据类型配对是否有好处:
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
<script src="http://maxcdn.bootstrapcdn.com/bootstrap/3.3.5/js/bootstrap.min.js"></script>
<link href="http://maxcdn.bootstrapcdn.com/bootstrap/3.3.5/css/bootstrap.min.css" rel="stylesheet"/>
<a href='#' class='btn' title ='Test' data-trigger='focus' data-toggle='popover' data-html='true' id = 'testOutside'>Click Here </a>
与仅使用二维列表相反:
[(23, "Jordan"), (8, "Bryant")]
我知道第二段代码在Haskell中不起作用
答案 0 :(得分:3)
如果我们可以使用二维列表,为什么我们使用元组?
因为列表和元组在概念上是不同的,所以类型系统为我们提供了一种有用的方式来陈述和识别代码中的差异。对于许多可能的例子中的一个,可以定义......
type ListyPair a = [a]
......然后......
listyFst :: ListyPair a -> a
listyFst [x, _] = x
listySnd :: ListyPair a -> a
listySnd [_, y] = y
......所以:
GHCi> listyFst [3,4]
3
GHCi> listySnd [3,4]
4
但如果listy“pair”只有一个元素,或者没有,会发生什么?我们必须抛出运行时错误(yuck),或者使listyFst
和listySnd
生成Maybe a
,以便我们可以干净地处理故障。如果“对”有两个以上的元素怎么办?我们应该默默地丢弃它们,还是在这种情况下使功能失败会更好?
从强类型系统用户的角度来看,当我们用ListyPair
替换实际的对时,我们会抛弃有用的信息。知道实际上只有两个元素可以让我们避免上述所有复杂情况。
realFst :: (a, b) -> a
realFst (x, _) = x
realSnd :: (a, b) -> b
realSnd (_, y) = y
答案 1 :(得分:1)
“为元组特别保留不同的数据类型配对是否有好处:”
是。使用元组的好处与数据周围的使用模式和任何性能要求有关。
元组通常是不可变的,并且具有可预测的大小。
由于你正在编写一个haskell程序,你的“字符串和整数”列表实际上是一个联合类型的列表(无论你想要什么,都可以调用它)......你的元组只是一个特例。
如果你把它想象成python代码,这一点就更清楚了。 (你提供的两个字符串都是有效的python代码;我原本认为这个问题与python有关)
在python中,如果你知道元组有一个固定的(或可预测的)结构,你会更喜欢元组列表。
这会让你编写如下代码:
[ print(name) for jersey, name in list_of_tuples ]
如果你认为支付对象表示的价格不值得,你会选择使用元组,并且你更喜欢用解包来表达每个元组引用。
幸运的是,既然您正在编写haskell,那么您可以使用许多工具来对类型系统中的问题进行建模和表示。我想如果你花点时间阅读并写一些haskell(了解一下Haskell for Great Good是一本好书),你将对类型系统有更好的理解,你会找到答案。你自己。
如果您希望了解有关函数式编程的更多信息,那么Little Schemer也非常引人注目。
((un)幸运的是,在python中你可以编写处理这两种数据结构的代码,而不是担心进入代码的类型.Haskell要求你思考一点不同。)
答案 2 :(得分:1)
这个问题应该更清楚地说明如下:
为什么我们必须坚持将列表定义为一种类型的元素集合?
从一个角度来看,答案可能是它允许我们以严格的方式推断列表,并且可以实现全新的操作。防爆。你还会如何为列表定义map
?
从另一个角度来看,如果列表可以容纳多种类型,那么语言就不能静态输入。防爆。如果你传递一个列表作为参数什么是头元素的类型?
元组没有这个问题,因为你先验地定义了每个元素的类型,并且长度是固定的。
为元组专门保留不同的数据类型配对是否有好处......
静态类型语言绝对有必要列出只包含一种类型的元素,因此利益问题没有任何好处。