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
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Jun Tomioka
July 18, 2018
Technology
0
260
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
370
ソフトウェアエンジニアとしてモナドを完全に理解する / 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
990
Introduction to Clean Architecture
jooohn
1
580
人類には早すぎる、謎の計算ロジックに立ち向かう / Strugle with the most complicated logic ever
jooohn
1
1.7k
Work at M3 USA
jooohn
0
1.4k
クラウド電子カルテを支えるテクノロジーの光と闇
jooohn
0
1.4k
怖くないCats
jooohn
0
870
Other Decks in Technology
See All in Technology
"共通化"と"Embed"のブレンドでスケール可能な運用を!M&Aを支えるGENDA SREの実践 / GENDA Tech Talk #3
genda
0
200
生成AIで始める業務改革 - 製造業編 in 福島 -
daikikanemitsu
2
570
猫でもわかるKiro CLI(セキュリティ編)
kentapapa
1
250
(技術的には)社内システムもOKなブラウザエージェントを作ってみた!
har1101
1
460
なぜAIは チーム開発を 速くしないのか
tan_go238
6
3k
ZOZO.swift #2
zozotech
PRO
0
270
xDS を活用したサービスディスカバリーで実現するブランチ別 QA 環境の構築手法
knwoop
1
140
SREチームをどう作り、どう育てるか ― Findy横断SREのマネジメント
rvirus0817
0
490
『誰の責任?』で揉めるのをやめて、エラーバジェットで判断するようにした ~感情論をデータで終わらせる、PMとエンジニアの意思決定プロセス~
coconala_engineer
0
840
バイブコーディングで作ったものを紹介
tatsuya1970
0
150
Claude Code で画面の仕様書を作ろう
zozotech
PRO
0
290
Amazon Rekognitionで 「信玄餅きなこ問題」を解決する
usanchuu
1
360
Featured
See All Featured
Design in an AI World
tapps
0
150
Building the Perfect Custom Keyboard
takai
2
700
YesSQL, Process and Tooling at Scale
rocio
174
15k
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
210
Large-scale JavaScript Application Architecture
addyosmani
515
110k
Joys of Absence: A Defence of Solitary Play
codingconduct
1
290
Optimizing for Happiness
mojombo
379
71k
30 Presentation Tips
portentint
PRO
1
240
Exploring anti-patterns in Rails
aemeredith
2
270
Prompt Engineering for Job Search
mfonobong
0
170
The SEO Collaboration Effect
kristinabergwall1
0
370
Become a Pro
speakerdeck
PRO
31
5.8k
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!