Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
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
270
0
Share
Why foldRight is beautiful
Explains why "foldRight" is beautiful.
Jun Tomioka
July 18, 2018
More Decks by Jun Tomioka
See All by Jun Tomioka
Dotty で軽量な DI ライブラリをかいてみた
jooohn
1
380
ソフトウェアエンジニアとしてモナドを完全に理解する / make-perfect-sense-of-monad
jooohn
14
8k
ScalaのコンパイラにFizzBuzzを解いてもらう(Dottyもあるよ)
jooohn
1
1.1k
Write stack safe non-tailrec recursive functions
jooohn
4
1k
Introduction to Clean Architecture
jooohn
1
590
人類には早すぎる、謎の計算ロジックに立ち向かう / Strugle with the most complicated logic ever
jooohn
1
1.8k
Work at M3 USA
jooohn
0
1.4k
クラウド電子カルテを支えるテクノロジーの光と闇
jooohn
0
1.4k
怖くないCats
jooohn
0
910
Other Decks in Technology
See All in Technology
変化の激しい時代をゴキゲンに生き抜くために 〜ストレスマネジメントのススメ〜
kakehashi
PRO
5
1.3k
2026年春のAgentCoreアプデ 細かいやつ全部まとめ
minorun365
3
230
10サービス以上のメール到達率改善を地道に継続的に進めている話 / Continue to improve email delivery rates across multiple services
yamaguchitk333
6
1.6k
LookerとADKで作る社内AIエージェント
chanyou0311
0
140
AI飲み会幹事エージェントを作っただけなのに
ykimi
0
180
ServiceによるKubernetes通信制御ーClusterIPを例に
miku01
1
160
SLI/SLO、「完全に理解した」から「チョットデキル」へ
maruloop
5
450
続 運用改善、不都合な真実 〜 物理制約のない運用改善はほとんど無価値 / 20260518-ssmjp-kaizen-no-value-without-physical-constraints
opelab
2
150
Vision Banana: Image Generators are Generalist Vision Learners
kzykmyzw
0
370
ブラウザの投機的読み込みと投機ルールAPIを理解し、Webサービスのパフォーマンスを最適化する
shuta13
3
300
生成AIはソフトウェア開発の革命か、ソフトウェア工学の宿題再提出なのか -ソフトウェア品質特性の追加提案-
kyonmm
PRO
2
900
AI時代に、 データアナリストがデータエンジニアに異動して
jackojacko_
0
810
Featured
See All Featured
Keith and Marios Guide to Fast Websites
keithpitt
413
23k
Technical Leadership for Architectural Decision Making
baasie
3
360
Designing Experiences People Love
moore
143
24k
Future Trends and Review - Lecture 12 - Web Technologies (1019888BNR)
signer
PRO
0
3.5k
The Spectacular Lies of Maps
axbom
PRO
1
740
Odyssey Design
rkendrick25
PRO
2
610
Optimizing for Happiness
mojombo
378
71k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
54k
Leo the Paperboy
mayatellez
7
1.8k
Heart Work Chapter 1 - Part 1
lfama
PRO
6
35k
[SF Ruby Conf 2025] Rails X
palkan
2
1k
Side Projects
sachag
455
43k
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!