We don’t allow questions seeking recommendations for software libraries, tutorials, tools, books, or other off-site resources. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(1)
,这也是一个愚蠢的任务。由于某种原因,Haskell课程一直以这种方式询问,但这很愚蠢。推断类型是编译器(特别是其Typechecker)的任务,或者是学习类型理论的另一种方法,而不是学习Haskell的人。
不要误会我的意思,这肯定是您最终可以轻松做的事情,但这不是您应该如何考虑Haskell代码。它几乎总是相反:您有一些上下文,您会看到一个差距知道它应该是什么,然后您找到与类型匹配的表达式表达式的类型。 (尽管有时您确实需要首先找出一个表达式的类型,以了解您需要写的表达式应该具有哪种类型。)
但是,您绝对需要学习的是理解类型签名。通过手练习类型的推断是到达那里的一种方法,但更有效的方法是两者都读了很多haskell代码。该代码的作用并不重要,只需选择您发现有趣的项目并查看其HADDOCK文档(通常最容易在 hackage )。选择任何功能,并尝试了解为什么给定描述对应于指定类型。然后查看源并通过实现跟踪类型。
另外,只要与GHCI一起玩很多玩具,想想您想解决的简单问题。也许像Project Euler这样的竞赛,但我从来没有亲自参加过。
Well, and that's a silly task too. For some reason Haskell courses keep asking it this way, but it's stupid. Inferring types is a task for a compiler (specifically its typechecker), or to put it another way for somebody learning type theory, but not for somebody learning Haskell.
Don't get me wrong, this is certainly something you will eventually be able to do easily, but it's not how you should in practice think about Haskell code. It almost always goes the other way around: you have some context, you see a gap an know what it's type is supposed to be, and then you find an expression that matches the type, not try to find the type of an expression. (Although, sometimes you do need to first find out the type of one expression in order to know what type the expression you need to write should have.)
However, what you absolutely need to learn is understanding type signatures. Practicing type inference by hand is one way of getting there, but more effective is to just both read an write lots of Haskell code. Doesn't really matter what the code does, just pick any project you find interesting and look at its Haddock documentation (usually easiest on Hackage). Pick any function, and try to understand why the given description corresponds to the specified type. Then look at the source and trace the types through the implementation.
Also, just toy around a lot with GHCi, think of simple problems you'd like to solve. Perhaps contests like Project Euler, but I never did that personally.