流程图绘制。这种古老的旧习惯已经使用了1000多年,被强加给我们贫穷的学生,没有任何用处(或者我认为是这样)。它可能适用于命令式,顺序运行的语言,但是我心爱的函数式编程呢?
可悲的是,我被迫为我的程序创建一个流程图(用Haskell编写)。
我想这样的事情很容易:
main :: IO ()
main = do
someInput <- getLine
let upped = map toUpper someInput
putStrLn upped
这只是3个顺序步骤,获取数据,加上数据,输出它。
这次事情看起来更糟:
main :: IO ()
main = do
someInput <- fmap toUpper getLine
putStrLn someInput
或者像这样:
main :: IO ()
main = interact (map toUpper)
好的,那就是IO,你可以像命令式语言那样处理它。纯函数怎么样?
一个实际的例子:
onlyMatching :: String -> [FilePath] -> [FilePath]
onlyMatching ext = filter f
where f name = lower ('.' : ext) == (lower . takeExtension $ name)
lower = map toLower
你如何描绘最后一张?
答案 0 :(得分:12)
我不认为代表流程(因此改变状态)的流程图适用于FP,它主要是无状态的。
但我认为你可以展示电路图(?)。
ext
_ | ______________________________________________
| | |
| `-> [ '.' : ] -------> [ lower ] --.__ |
| __ [ == ] ----->
name --> [ takeExtension ] ---> [ lower ] --' |
|__________________________________________________|
f
你最好咨询教练。
答案 1 :(得分:4)
实际上,flowcharts用于软件的日期仅为60年左右。 (实际上,编程,正如我们所知,它的历史可以追溯到65岁!)当时它们作为在“编码”这个非常繁琐且容易出错的阶段之前规划和开发算法的工具非常重要。
现在,我们的编程语言已达到表达能力水平,其中算法的意图更清晰地由代码本身表达。 (或许在VisualBasic中没那么多,但肯定在Haskell中。)因此,没有现代编程工作室使用流程图。
然而,visual programming languages存在,并且在某些领域取得了巨大成功。这些环境与流程图有关。也许你的导师真的准备做一些比较编程语言的工作,并引导大家思考这些方法。
最后,针对您手头的具体问题,请以这种方式思考:传统的流程图主要通过程序展示了控制流程,因为这是人们当时编写的代码。但是,总有一些数据流也被说明了。对于功能程序,您将主要演示数据流。
然而,诀窍是弄清楚如何将(部分应用的)函数的流程说明为数据。想一想流程图必须做什么来支持可以在两个地方调用的子程序的概念......现在也许你可以创建类似的图形构造来表示“由identified识别的函数作为{{1的第二个参数流入” “我想象一个标有filter
的小弓,侧面有一个钥匙孔,用于连接箭头。
如果不出意外,可以将此视为探索程序的替代表示的一项任务 - 如果您已经扩展了流程图(从不必处理通用函数),并且明确说明,那么您的教师应该给您额外的马克!
答案 2 :(得分:2)
嗯...您可以手动将代码编译为基于超级组合器的表示,然后绘制该超级组合器应用程序的类似流程图的图表。在某些情况下,这样做甚至是有用的,给出一些合理的流动视觉表示。只需考虑数据流而不是执行流程。
答案 3 :(得分:1)
流程图和FP的线索是您开始考虑功能流程。 正如您现在所知道的那样,FP构建了调用函数来完成工作的函数。 如果你没有一个良好的形象,谁会打电话给谁,你最终会创建意大利面条代码或创建大量功能,使你的代码很难维护
使用流程图创建您计划构建的结构化图表,描述事情必须发生的顺序,最终将得到一个可维护且更易于测试的程序。
对于那些不熟悉结构图的人来说,这是一种通过发送和返回值来模拟从调用者到接收者的函数调用的方法。有了它,如果你已经有一个函数从ie配置文件中检索数据并在系统的任何地方重复使用它,你可以轻松实现海洋