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
160
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
250
ソフトウェアエンジニアとしてモナドを完全に理解する / make-perfect-sense-of-monad
jooohn
14
7.2k
ScalaのコンパイラにFizzBuzzを解いてもらう(Dottyもあるよ)
jooohn
1
820
Write stack safe non-tailrec recursive functions
jooohn
4
720
Introduction to Clean Architecture
jooohn
1
520
人類には早すぎる、謎の計算ロジックに立ち向かう / Strugle with the most complicated logic ever
jooohn
1
1.5k
Work at M3 USA
jooohn
0
1.1k
クラウド電子カルテを支えるテクノロジーの光と闇
jooohn
0
1k
怖くないCats
jooohn
0
660
Other Decks in Technology
See All in Technology
開発生産性向上サービスを作るFindyが自分たちで開発生産性を爆上げした組織づくりの歩み / Findy's path to boosting its own development productivity 2024-04-17
ma3tk
0
240
Databricks:『生成AI World Cup』のご案内
databricksjapan
1
130
Garoon 開発チーム / Garoon development team
cybozuinsideout
PRO
1
2.9k
巨大なテーブルのテーブル定義を無停止で安全に誰でも変更できるようにする / Table-definitions-for-huge-tables-can-be-modified-by-anyone-safely-and-non-disruptively
freee
1
720
[2024年3月版] Databricksのシステムアーキテクチャ
databricksjapan
7
1.9k
Algyan イベント振り返り
linyixian
0
180
カオナビの利用実績をアウトカムへつなげる旅 / example-of-data-management-startup-in-kaonavi
kaonavi
0
110
自動生成を活用した、運用保守コストを抑える Error/Alert/Runbook の一元集約管理 / Centralized management of Error/Alert/Runbook to minimize operational costs using automated code generation
biwashi
9
2k
入社後初めてのタスクでk8sアップグレードした話.pdf
kkato1
0
380
「ふりかえりのふりかえり」をふりかえり、実のあるふりかえりにする
naitosatoshi
0
210
2024/4/26 コンピュータ歴史博物館解説告知
toshi_atsumi
0
190
最近たまに見かけるTiDBってなんだ? - Findy
pingcap0315
2
420
Featured
See All Featured
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
219
21k
RailsConf 2023
tenderlove
1
530
How GitHub (no longer) Works
holman
304
140k
The World Runs on Bad Software
bkeepers
PRO
61
6.7k
Fireside Chat
paigeccino
19
2.6k
What's new in Ruby 2.0
geeforr
336
31k
How GitHub Uses GitHub to Build GitHub
holman
468
290k
Building an army of robots
kneath
300
41k
Being A Developer After 40
akosma
56
580k
The MySQL Ecosystem @ GitHub 2015
samlambert
242
12k
Raft: Consensus for Rubyists
vanstee
131
6.2k
Navigating Team Friction
lara
177
13k
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!