Monad typeclass不是一种类型,而是一种程序设计模式(design pattern),是泛函编程中最重要的编程概念,因而很多行内人把FP又称为Monadic Programming
我们在前面花了几期时间讨论Free Monad,那是因为FP既是Monadic programming,Free Monad是FP模式编程的主要方式。对我们来说,Free Monad代表着fp从学
前面提到了scalaz是个函数式编程(FP)工具库。它提供了许多新的数据类型、拓展的标准类型及完整的一套typeclass来支持scala语言的函数式编程模式。我们知道:对于任何类型,我们只需
中间插播了几篇scalaz数据类型,现在又要回到Monad专题。因为FP的特征就是Monad式编程(Monadic programming),所以必须充分理解认识Monad、熟练掌握Monad运用。
经过了一段时间的学习,我们了解了一系列泛函数据类型。我们知道,在所有编程语言中,数据类型是支持软件编程的基础。同样,泛函数据类型Foldable,Monoid,Functor,Applicat
简单来说:Monad就是泛函编程中最概括通用的数据模型(高阶数据类型)。它不但涵盖了所有基础类型(primitive types)的泛函行为及操作,而且任何高阶类或者自定义类一旦具备Monad
scala中的Option类型是个很好用的数据结构,用None来替代java的null可以大大降低代码的复杂性,它还是一个更容易解释的状态表达形式,比如在读取数据时我们用Some(Row)来代表读取的数据行Row,用None来代表没有读到任何数据,免去了null判断。由此我们可以对数据库操作的结果有一种很直观的理解。同样,我们又可以用Either的Right(Row)来代表成功运算获取了结果Row,用Left(Err)代表运算产生了异常Err。对于数据库编程我还是选择了Task[Either[E,Option[A]]]这种类型作为数据库操作运算的统一类型。可以看到这是一个复合类型:首先Task是一个non-blocking的运算结果类型,Either[E,Option[A]]则同时可以处理发生异常、获取运算结果、无法获取结果几种状态。我觉着这样已经足够代表数据库操作状态了。
在上一节我们介绍了Monad。我们知道Monad是一个高度概括的抽象模型。好像创造Monad的目的是为了抽取各种数据类型的共性组件函数汇集成一套组件库从而避免重复编码。这些能对什么是Monad
最近,出版社邀请我作为分享导师为Bruce Eckel的大作OnJava录制部分视频,视频内容主要面向Java初学者。录制到14.4章节,书中详细介绍了Java 8引入的Optional类型,我忽然想起很早以前写的一篇文章《并非Null Object这么简单》。
该文章介绍了如何使用Monoid类型进行并行计算和并行序列化。首先介绍了Monoid的概念,以及如何使用Scalaz库中的Monoid类型进行并行计算。然后介绍了如何使用Monoid类型进行并行序列化,并提供了几个例子。最后还介绍了如何使用Monoid类型进行并行处理,并提供了几个例子。
上两期我们讨论了Monad。我们说Monad是个最有概括性(抽象性)的泛函数据类型,它可以覆盖绝大多数数据类型。任何数据类型只要能实现flatMap+unit这组Monad最基本组件函数就可以
在前面的几篇讨论里我们初步对FP有了些少了解:FP嘛,不就是F[A]吗?也是,FP就是在F[]壳子(context)内对程序的状态进行更改,也就是在F壳子(context)内施用一些函数。再直白一
前面我们讨论了Applicative。Applicative 就是某种Functor,因为我们可以用map2来实现map,所以Applicative可以map,就是Functor,叫做Appl
https://www.reddit.com/r/rust/comments/k4vzvp/gats_on_nightly/
Monad Reader就是一种函数的组合。在scalaz里函数(function)本身就是Monad,自然也就是Functor和applicative。我们可以用Monadic方法进行函数组合:
刚完成了9月份深圳scala-meetup,趁刮台风有空,把我在meetup里的分享在这里发表一下。我这次的分享主要分三个主题:“Monadic编程风格“、”Future vs Task and ReaderMonad应用方法“及”using heterogeneous monads in for-comprehension with MonadTransformer“。这篇想先介绍一下Monadic编程风格。
本文介绍了如何使用函数式编程的方式处理IO,并使用Scalaz的IO Monad实现了一个简单的程序。通过这个例子,展示了函数式编程在处理异步逻辑中的优势。
说道FP,我们马上会联想到Monad。我们说过Monad的代表函数flatMap可以把两个运算F[A],F[B]连续起来,这样就可以从程序的意义上形成一种串型的流程(workflow)。更直白的讲
scalaz-stream是一个泛函数据流配件库(functional stream combinator library),特别适用于函数式编程。scalar-stream是由一个以上各种状
再次看了看上篇博客的源代码,发现连自己都看不懂了。想是为了赶时间交货不知不觉又回到OOP行令模式了,看看下面这段代码:
在前面的几篇关于Free编程的讨论示范中我们均使用了基础类型的运算结果。但在实际应用中因为需要考虑运算中出现异常的情况,常常会需要到更高阶复杂的运算结果类型如Option、Xor等。因为Mona
本文探讨了函数式编程在软件工程领域中的应用,包括函数式编程的优缺点,与面向对象编程的区别,以及如何在实践中应用函数式编程。作者还探讨了函数式编程和形式方法的关系,并介绍了一些函数式编程的工具和语言。
本文为稀土掘金技术社区首发签约文章,14天内禁止转载,14天后未获授权禁止转载,侵权必究!
使用git提交代码的时候报异常:refusing to merge unrelated histories
原文: http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html 参考文章: http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf
我们经常提到函数式编程就是F[T]。这个F可以被视为一种运算模式。我们是在F运算模式的壳子内对T进行计算。理论上来讲,函数式程序的运行状态也应该是在这个运算模式壳子内的,也是在F[]内更新的。那么
basically, parser combinator (But 非常麻烦 in Coq)
上节我们讨论了Zipper-串形不可变集合(immutable sequential collection)游标,在串形集合中左右游走及元素维护操作。这篇我们谈谈Tree。在电子商务应用中对于xm
看到函数式编程相关的资料的时候, 总是看到 Monad 这个词, 一直想了解一下, 然而查资料对 Monad 的定义往往是上来一大堆数学概念:
通过前面的几篇讨论我们了解到F[T]就是FP中运算的表达形式(representation of computation)。在这里F[]不仅仅是一种高阶类型,它还代表了一种运算协议(computa
函数式编程的精髓就在于,我们可以用好多好多小小函数,搭搭搭,组成一个个大函数,最终写出整个程序来。比如我们想写一个函数
管道文本处理 1. tr 命令 删除 转换 删除一段文本信息中的某些文字。或者将其进行转换。 tr [option]...SET1 [SET2] 选项 说明 -d 删除和 set1 匹配的字符,注意不是全词匹配也不是按字符顺序匹配 -s 去除 set1 指定的在输入文本中连续并重复的字符 # 删除 "hello shiyanlou" 中所有的'o','l','h' $ echo 'hello shiyanlou' | tr -d 'olh' # 将"hello" 中的ll,去重为一个l $ echo 'h
国庆前,参与了一个c# .net 项目,真正重新体验了一把搬砖感觉:在一个多月时间好像不加任何思考,不断敲键盘加代码。我想,这也许是行业内大部分中小型公司程序猿的真实写照:都是坐在电脑前的搬砖工人。不过也不是没有任何收获,在搬砖的过程中我似乎发现了一些现象和造成这些现象背后的原因及OOP思维、习惯模式。和大部分IT公司一样,这间公司在行业里存在了一定时间(不是初创)所以在产品和技术方面有一定的积累,通俗点就是一堆现成的c# .net 代码。然后就是项目截止日期压力。为了按时完成任务的我只能在原有代码基础上不断加功能,根本没有机会去考虑用什么样的代码模式、结构去达到更好的效果。在这个过程中有个有趣的现象引起了我的注意:基本上我只需按照某种流程(多数是业务需求)一个个增加环节就可以实现一项完整功能,当然我是不会计较这些环节对软件其它部分是否产生影响,又或者以后代码维护会不会很麻烦,只要能及时交货就行。想想这种做法恰恰是面向对象编程或所谓行令式编程的特点,即:通过逐行执行命令引导程序的状态改变,最终状态就是运行程序的结果了,或者就是功能的实现了。通过一行行增加代码最终总会到达预期的状态,不是吗。这正是OO编程的思维模式:因为程序状态体现在每行代码上,随时可以检查,验证思路,所以OOP比较容易上手(相对函数式编程而言)。
由于泛函编程非常重视函数组合(function composition),任何带有副作用(side effect)的函数都无法实现函数组合,所以必须把包含外界影响(effectful)副作用不
一直有个疑惑,Haskell号称纯函数式语言,那么铁定不纯的场景(肯定有副作用,或者操作本身就是副作用)如何解决?
在上篇中,我们分析了函数式编程的起源和基本特性,并通过每一个特性的示例来演示这种特性的实际效果。首先,函数式编程起源于数理逻辑,起源于λ演算,这是一种演算法,它定义一些基础的数据结构,然后通过归约和代换来实现更复杂的数据结构,而函数本身也是它的一种数据。其次,我们探讨了很多函数式编程的特性,比如:
函数式编程是一种历史悠久的编程范式。作为演算法,它的历史可以追溯到现代计算机诞生之前的λ演算,本文希望带大家快速了解函数式编程的历史、基础技术、重要特性和实践法则。
我们会频繁地使用Scala的Option,用以解决类似Null Object之类的问题。某种程度讲,使用Option必然会减少对空指针引用判断的丑陋代码,结合For Comprehension,确乎是Scala编程中的一把利器。我在博客《引入Option优雅地保证健壮性》与《并非Null Object这么简单》中都详细对Option的本质与运用进行剖析与介绍。 然而,Option虽然好,我们却不可“贪杯”哦! 从语义上讲,Option代表一种容器(Monad)非空即有的两种状态,例如List的headOpt
我在上期讨论里已经成功的创建了一个简单的Slick项目,然后又尝试使用了一些最基本的功能。Slick是一个FRM(Functional Relational Mapper),是为fp编程提供的sc
REA的Ken Scambler在其演讲《2 Year of Real World FP at REA》中,总结了选择函数式编程的三个原因:Modularity, Abstraction和Composability。 函数式编程强调纯函数(Pure Function),这是模块化的一个重要基础,因为对于纯函数而言,可以不用考虑调用的上下文,就可以根据函数的输入推断函数的执行结果。这也就是Ken所谓的: You can tell what it does without Looking at surround
继承和重写是面向对象编程语言中的概念,是指一个类扩展自父类,并且重新实现了其中一些属性、方法。这种思想不只是在编程语言中会用到,在配置文件中也有广泛的应用。
文章背景: 在工作中,有时需要将多个工作簿进行合并,比如将多份原始数据附在报告之后。一般的操作方法是打开两个工作簿(目标工作簿和待转移的工作簿),然后选中需要移动的工作表,右键单击以后选择“移动或复制”。接下来在新的对话框里面进行设置。
最近,新项目架构搭建在扩展组件的场景中:图表使用了extends方式,而公共业务server和view之间使用了mixins方式。对于二者的选择,我们通常会解释为extends的优先级高于mixins,但其真实的差异是由于其合并策略不同或者说在合并策略中执行的顺序不同导致的 – 源码
关于Git Flow 工作流,我想已经是老生常谈的话题了,但是今天我不得不来重温一下 Git Flow 工作流。当我看的代码厂库的时候,我已经开始怀疑人生。乱七八糟的分支,五花八门的提交信息,各种各样的分支名称,没有 Develop 分支,没有 Release,也没有 Hotfix。因此我想我应该好好温习一遍 Git Flow 工作流,来改善一下厂库现状。
但是在上线前总要先merge master,但是master的两次revert是领先你的,一旦merge后你的代码就没有了。
昨天的文章删了,因为我的 vscode 把 markdown 里的 * 自动替换成了 _,导致一些公式的表述变得异常奇怪。另外,原创忘记打开了。
--include-untracked 参数可以额外储藏新的未被追踪的文件。 --all 选项将收集所有未跟踪的文件以及在 .gitignore 和 排除文件中明确忽略的文件。
领取专属 10元无门槛券
手把手带您无忧上云