Cla*_*nny 3 functional-programming
我目前正在学习Clojure并且它在智力上非常刺激,但是我遇到了很多情况,我可以编写一个问题的解决方案(例如4Clojure),但是找到其他解决方案来使用大量的其他函数我完全没有意识到.
除了阅读所有文档或至少所有名称空间之外,还有解决方案来解决函数式编程中的可发现问题吗？这个问题的必然结果是,如果有一个解决方案,不能在软件工程团队中重复人员之间的努力.如果我需要一个新功能,或者我的队友已经实现了它,有没有办法可以发现？有没有办法让她发现我的功能？也就是说,如果没有我们正在构建的整个系统的某种总体功能分解.
是否存在可以帮助我发现基于使用的新功能的本体或函数映射.例如,一种分类foldl和foldr的方法,这样我就可以很容易地发现foldl'存在(或可能存在)和foldr'不需要存在？在某种程度上,我可以看到地图的"黑暗区域",并知道那里可能有一个功能,它会做什么.
是否存在某个问题的数据库或解决它们的数据类型和功能？
根据许多人的良好开端是能够谈论类型.在Haskell世界中,他们甚至拥有基于类型的搜索引擎!例如,假设您有一个类型的值,Maybe Int并且您希望将其转换为字符串(如果有值),否则提供空字符串.在类型方面,这是一个功能
f' :: Maybe Integer -> (Integer -> String) -> String -> String
它需要三个参数 - Maybe值,转换函数,默认值,它将返回一个字符串.如果我们把它变得更加通用,我们可能会得到类似的东西
f :: Maybe a -> (a -> b) -> b -> b
通过使用它作为基于类型的搜索引擎的查询,我们将发现确实存在一个函数
maybe :: b -> (a -> b) -> Maybe a -> b
在Data.Maybe图书馆做我们想要的.
当然,这并不完美.一个问题是您可以在不同的抽象级别表达相同的操作.想象一下,例如,我们有一个整数列表,我们想要转换为Text值然后连接.对类型签名的第一次尝试会产生类似的东西
g' :: [Int] -> (Int -> Text) -> Text
如果我们搜索这个,我们找不到明确的结果.可能不会立即明确如何使这更抽象.也许它应该是这样的？
g :: [a] -> (a -> b) -> ([b] -> b) -> b
(换句话说,给定一个a转换函数的列表,以及一个告诉你如何连接bs 的函数,返回一个b.)搜索它会产生各种结果,所有结果都与我们的应用程序完全无关.
这里的关键见解,不是推理,而是经验和知识,是我们真正想要的东西已经知道如何连接自己.我们想要一个Monoid操作功能.基于这些知识,我们更有可能找到
foldMap :: (Foldable t, Monoid m) => (a -> m) -> t a -> m
- 正是我们要找的.
所以类型不是一个完美的系统,但它们确实有帮助.他们工作的原因是因为他们试图编码程序员的意图.你真正要求的是一种意图数据库,而不是实现(源代码是.)
更好的类型系统只能让程序员更好地编码他们的意图,从而使这个过程更顺畅.但他们总是需要纪律,例如使用最常用的类型.
更一般类型的情况是更一般的类型限制属于同一类型的意图的数量.a -> b -> a在没有上下文的情况下,具有类型的函数只能执行一项操作 - 忽略其第二个参数并返回第一个参数.另一方面,类型函数String -> b -> String可以做任何想做的事情,因为它知道如何构造自己的返回类型的值.如果函数不知道它的返回类型,它只能通过使用它获得的参数来构造它.