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
0
230
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
330
ソフトウェアエンジニアとしてモナドを完全に理解する / make-perfect-sense-of-monad
jooohn
14
7.7k
ScalaのコンパイラにFizzBuzzを解いてもらう(Dottyもあるよ)
jooohn
1
1k
Write stack safe non-tailrec recursive functions
jooohn
4
920
Introduction to Clean Architecture
jooohn
1
550
人類には早すぎる、謎の計算ロジックに立ち向かう / Strugle with the most complicated logic ever
jooohn
1
1.7k
Work at M3 USA
jooohn
0
1.3k
クラウド電子カルテを支えるテクノロジーの光と闇
jooohn
0
1.3k
怖くないCats
jooohn
0
800
Other Decks in Technology
See All in Technology
SaaS公式MCPサーバーをリリースして得た学び
kawamataryo
4
1.1k
CodeRabbitと過ごした1ヶ月 ─ AIコードレビュー導入で実感したチーム開発の進化
mitohato14
1
250
RubyKaigi NOC 近況 2025
sorah
1
880
Next.jsと状態管理のプラクティス
uhyo
5
2k
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
7
64k
本当に必要なのは「QAという技術」だった!試行錯誤から生まれた、品質とデリバリーの両取りアプローチ / Turns Out, "QA as a Discipline" Was the Key!
ar_tama
9
4.4k
Azure × MCP 入門
ry0y4n
8
1.7k
250510 StepFunctionのテスト自動化始めました vol.1
east_takumi
1
220
地に足の付いた現実的な技術選定から魔力のある体験を得る『AIレシート読み取り機能』のケーススタディ / From Grounded Tech Choices to Magical UX: A Case Study of AI Receipt Scanning
moznion
4
1.4k
非root化Androidスマホでも動く仮想マシンアプリを試してみた
arkw
0
120
Google Cloud Next 2025 Recap アプリケーション開発を加速する機能アップデート / Application development-related features of Google Cloud
ryokotmng
0
180
Sleep-time Compute: LLM推論コスト削減のための事前推論
sergicalsix
1
120
Featured
See All Featured
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
24
2.7k
The Invisible Side of Design
smashingmag
299
50k
The Cult of Friendly URLs
andyhume
78
6.3k
Designing Experiences People Love
moore
142
24k
What's in a price? How to price your products and services
michaelherold
245
12k
Making Projects Easy
brettharned
116
6.2k
Reflections from 52 weeks, 52 projects
jeffersonlam
349
20k
GitHub's CSS Performance
jonrohan
1031
460k
Scaling GitHub
holman
459
140k
Fireside Chat
paigeccino
37
3.4k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
21k
Git: the NoSQL Database
bkeepers
PRO
430
65k
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!