$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Why foldRight is beautiful
Search
Jun Tomioka
July 18, 2018
Technology
0
250
Why foldRight is beautiful
Explains why "foldRight" is beautiful.
Jun Tomioka
July 18, 2018
Tweet
Share
More Decks by Jun Tomioka
See All by Jun Tomioka
Dotty で軽量な DI ライブラリをかいてみた
jooohn
1
360
ソフトウェアエンジニアとしてモナドを完全に理解する / make-perfect-sense-of-monad
jooohn
14
7.9k
ScalaのコンパイラにFizzBuzzを解いてもらう(Dottyもあるよ)
jooohn
1
1.1k
Write stack safe non-tailrec recursive functions
jooohn
4
970
Introduction to Clean Architecture
jooohn
1
570
人類には早すぎる、謎の計算ロジックに立ち向かう / Strugle with the most complicated logic ever
jooohn
1
1.7k
Work at M3 USA
jooohn
0
1.4k
クラウド電子カルテを支えるテクノロジーの光と闇
jooohn
0
1.3k
怖くないCats
jooohn
0
860
Other Decks in Technology
See All in Technology
Ryzen NPUにおけるAI Engineプログラミング
anjn
0
210
eBPFとwaruiBPF
sat
PRO
2
960
Master Dataグループ紹介資料
sansan33
PRO
1
4k
Databricksによるエージェント構築
taka_aki
1
120
私のRails開発環境
yahonda
0
180
MCP・A2A概要 〜Google Cloudで構築するなら〜
shukob
0
160
バグハンター視点によるサプライチェーンの脆弱性
scgajge12
2
440
Active Directory 勉強会 第 6 回目 Active Directory セキュリティについて学ぶ回
eurekaberry
16
5.9k
セキュリティAIエージェントの現在と未来 / PSS #2 Takumi Session
flatt_security
3
1.4k
会社紹介資料 / Sansan Company Profile
sansan33
PRO
11
390k
Product Engineer
resilire
0
130
形式手法特論:CEGAR を用いたモデル検査の状態空間削減 #kernelvm / Kernel VM Study Hokuriku Part 8
ytaka23
1
140
Featured
See All Featured
Building Adaptive Systems
keathley
44
2.9k
GraphQLとの向き合い方2022年版
quramy
50
14k
Git: the NoSQL Database
bkeepers
PRO
432
66k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
659
61k
Bash Introduction
62gerente
615
210k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Building Applications with DynamoDB
mza
96
6.8k
Java REST API Framework Comparison - PWX 2021
mraible
34
9k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.4k
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
Product Roadmaps are Hard
iamctodd
PRO
55
12k
Scaling GitHub
holman
464
140k
Transcript
Why foldRight is beautiful Jun Tomioka (M3, inc.)
M3, Inc. Jun Tomioka Twitter: @jooohn1234 Github: jooohn Love: Our
very first baby Had great paternity leave!
None
foldLeft / foldRight
trait List[+A]
foldLeft[B](z: B)(op: (B, A) => B): B A A A
A A B A A A A B B OP ...
foldRight[B](z: B)(op: (A, B) => B): B A A A
A A B A A A A B B OP ...
So what’s the difference between them?
Suppose you define your own Linked List
foldLeft would be like this
foldRight would be like this
This naive foldRight can cause stack overflow
If so, why can foldRight be beautiful?
Let’s implement “map” with foldLeft
A A A A A List[B] A A A A
OP ... List[B] List[B]
Let’s implement “map” with foldLeft
foldRight
Let’s implement “map” with foldRight
A A A A A List[B] A A A A
List[B] List[B] OP ...
Why is it that natural to write “map” with foldRight?
Immutable recursive data structure
Bigger part holds smaller part
We must create them from smaller part to bigger part
This is the folding order of foldRight
foldRight folds items by its creation order
Why foldRight is beautiful • Immutable recursive data structure is
built from smaller part to bigger part • In this sense, foldRight folds items from smaller part to bigger part rather than from right to left ◦ Is quite natural to treat immutable recursive data structure
Thanks!