Memory management & concurrency model in Kotlin/Native

Видео с докладом Николая Иготти про многопоточность и управление памятью в Kotlin/Native.

https://www.youtube.com/watch?v=nw6YTfEyfO0&index=20&list=PLQ176FUIyIUbVvFMqDc2jhxS-t562uytr

Многое лучше, чем например в Swift, как минимум с поддержкой на уровне языка асинхронно исполняемых блоков кода и многопоточности.
В Swift пока не ушли дальше GCD (libdispatch) - внешнего библиотечного и очень неэлегантного решения на базе очередей сообщений, на базе которого есть внешние библиотечные решения для Futures/Promises.
Но в Swift нет сопрограмм и поддержки асинхронной многопоточности на уровне языка и компилятора (https://t.me/technologique/1098).
Лучшее что есть для Swift это Venice (https://github.com/Zewo/Venice) - библиотека сопрограмм, также внешнее библиотечное решение и лишняя внешняя зависимость в проекте.

Но вернёмся к Kotlin/Native.
В общем и целом проект языка пока не очень впечатляет чем-то кардинально новым - ARC, cyclic garbage collector, actor'ы с thread local job queue (request queue) очередями, и пока всё.
Общий проект языка пока выглядит очень сырым.
На уровне системы типов, как в Rust на базе субструктурной системы линейных/уникальных типов или в Pony на базе reference/object capabilities, поддержки многопоточной иммутабельности данных нет.
Есть поддержка сопрограмм - https://github.com/Kotlin/kotlinx.coroutines/tree/master/native
Но сопрограммы не многопоточные, работают только в цикле событий (event loop) основного потока исполнения программы, т.е. не могут исполняться в цикле событий на других потоках, только в основном - это ограничения реализации библиотеки сопрограмм, пока что.
Также пока нет коммуникации между сопрограммами в разных тредах через каналы (внешние очереди сообщений).
Всё это описано в данном тикете самим Романом Элизаровым и пока в процессе реализации - https://github.com/Kotlin/kotlinx.coroutines/issues/462

В языке нет тайп-классов и структур.

Наличие различных видов специализированных классов для разых целей в Kotlin (и также в Scala) - это не очень удачный элемент дизайна языка.
Самым базовым для высших абстракций является наличие в языке классов типов (type classes, traits/типажей) - Scala поддержкивает тайп-классы, Kotlin пока нет.

Отсутствует поддержка структур и типов на базе структур, даже в Kotlin/Native (также и в Scala Native).
Вместо структур также классы - data class'ы в Kotlin (case class'ы в Scala).
Отсутствие структур вообще весьма странно для нативного языка, как минимум в плане interoperability с кодом через FFI, а также для использования структур для поддержки и форммирования абстрактных типов данных на их базе.

https://github.com/JetBrains/kotlin-native/blob/master/INTEROP.md

https://github.com/scala-native/scala-native/blob/master/docs/user/interop.rst

Ссылки на предыдущие материалы по теме:
https://t.me/technologique/1188
https://t.me/technologique/1190
https://t.me/technologique/1191
https://t.me/technologique/1201

Functional Kotlin - Arrow

Рауль Райя Мартинез о функциональном программировании на языке Kotlin:

https://www.youtube.com/watch?v=VOZZTSuDMFE&list=PLQ176FUIyIUbVvFMqDc2jhxS-t562uytr&index=36

В проекте фреймворка Kategory (https://t.me/technologique/1267, https://t.me/technologique/1268, https://t.me/technologique/1269) за год произошли большие изменения - был объединён функционал с проеком FunKtionale (https://github.com/MarioAriasC/funKTionale), также фреймворк получил много новых возможностей.
Теперь фреймворк называется Arrow.
Есть возможности для создания классов типов (пока с run-time специализацией типов), функциональных структур данных, эффектов, оптики (optics), линз (lenses), призм (prisms), монад, функторов и прочих высших функциональных абстракций, функциональных структур данных, композиций функций для обработки данных и преобразования структур данных (optics, lenses, prisms).

https://github.com/arrow-kt/arrow

https://github.com/arrow-kt/arrow/commit/6df61a2afc825b6f0a1d946fe6354fd92c7cdfb7

Ad-hoc подстановка конкретного типа, т.е. специализация типа из тайп-класса в фреймворке пока происходит во время исполнения кода в run-time.

Добавление type class'ов в сам язык Kotlin многое бы упростило не только в фреймворке Arrow, это позволило бы иметь поддержку высших абстракций на уровне языка, а не только отдельного фреймворка, что было бы элегантнее, на уровне синтаксиса языка.

Для статической мономорфизации типов в тайп-классах при компиляции авторы Arrow предложили синтаксис тайп-классов (пока не окончательный) для включения в язык и соответственно в компилятор (KEEP-87):

https://github.com/arrow-kt/kotlin/pull/6

https://github.com/Kotlin/KEEP/pull/87

https://github.com/47deg/KEEP/blob/master/proposals/type-classes.md

Но пока в Kotlin нет тайп-классов - нет и высших абстракций с compile-time оптимизациями.

Вообще это интересная и довольно сложная тема...

Когда специализация типа (обобщённого/дженерика, типа из тайп-класса) со статической генерацией кода для его подстановки происходит через субструктурный (ad-hoc) вывод типов/подтипов на этапе компиляции в compile-time (ad-hoc специализация с подстановкой), проверяется структурное соответствие типов параметру (т.е. какие типы данных может принимать и обрабатывать функция/метод через обобщённый параметр, а какие нет) для параметрически полиморфных типов, либо проверяются структурные зависимости типа для зависимых типов и их специализации, и при соответствии типов (и их зависимостей для зависимых типов) параметру генерируется специализированный код функций/методов обработки типов данных, а сама ad-hoc подстановка конкретного обработчика происходит уже во время исполнения кода в run-time в зависимости от приходящих типов данных в общий интерфейс обработчиков, который и выполняет подстановку специализированного обработчика.

В C++ и D это шаблоны, которые обрабатываются препроцессором, который генерирует код специализации типов для них.

В Rust это типажи (трейты, те же тайп-классы со статической мономорфизацией).
В Scala 2 есть тайп-классы, в Scala 3 это ещё и зависимые типы в тайп-классах.
Правда в Scala специализированный код обработки типов генерируется в виде байт-кода для JVM.

В Haskell есть first-class поддержка тайп-классов в языке. Более того система типов языка и все высшие функциональные абстракции (higher-order abstractions, как например монады, функторы) построены полностью на базе тайп-классов.
Но в Haskell используются ленивые вычисления (lazy evaluation), что замедляет ad-hoc подстановку специализированного кода обработки типов данных и скорость исполнения кода соответственно. При этом специализация типов достигается мономорфизацией полиморфных типов в тайп-классах с генерацией кода в промежуточный низкоуровневый язык C-- (GHC) и далее в машинный код.

Ссылки на предыдущие материалы по теме:
https://t.me/technologique/1267
https://t.me/technologique/1268
https://t.me/technologique/1269

Gradual typing... Gradual GC...

Отличная статья Стива Клабника (Rust Core Developer) о принципах управления памятью в Rust с множеством интересных метаморфоз - например Стив очень корректно разделил compile-time/static и run-time/dynamic фазы компиляции, исполнения, типизации, автоматического управления памятью и сборки мусора (GC) программ.
Такие статьи несут много смыслов и заставляют задуматься о базовых принципах работы программ.

https://words.steveklabnik.com/borrow-checking-escape-analysis-and-the-generational-hypothesis

#Rust

Multi-threading & Multi-processing for Python

Одни из лучших (если не самые лучшие) библиотечные решения для создания и управления thread-pools и process-pools для Python, обхода GIL ограничений интерпретатора CPython в плане многопоточной обработки данных и работы с реальной системной многогопоточностью (системными потоками), вытесняющей (pre-emptive) многозадачностью, для создания thread-mapper'ов (M:N dispatcher/scheduler/monitor) программных потоков сопрограмм/генераторов/asyncIO на системные треды.
Естественно у данных решений есть своя цена, overhead и накладные расходы.

https://github.com/eXascaleInfolab/PyExPool

https://github.com/noxdafox/pebble
https://pypi.org/project/Pebble/
https://pebble.readthedocs.io/en/latest/

#Python
#multithreading
#multiprocessing

Starlink by SpaceX

Модель спутниковой mesh-сети Starlink от SpaceX с минимизацией задержек маршрутизации трафика.

https://www.youtube.com/watch?v=AdKNCBrkZQ4&

Сoroutines & non-blocking operations

Статья Романа Элизарова о том как использовать и корректно реализовать неблокирующую семантику на базе сопрограмм и при исполнении кода не блокировать треды и основной поток исполнения приложения, а также чем отличается семантика suspended functions, на базе которых построены сопрограммы и неблокирующий IO в Kotlin, от блокировок для системных потоков.

https://medium.com/@elizarov/blocking-threads-suspending-coroutines-d33e11bf4761

#Kotlin

Shenandoah GC

Роман Кеннке (Shenandoah Project Lead, RedHat) о проекте Shenandoah на конференции Oracle Code One.
Shenandoah - проект сборщика мусора (garbage collector, GC) нового поколения для автоматического управления выделением и освобождением памяти для JVM (OpenJDK).
Главным преимуществом Shenandoah GC является многопоточный режим сборки мусора, также в фазе Compact (уплотнения фрагментов памяти), с максимальной минимизацией остановок/задержек потоков (stop-the-world, STW) при операциях с памятью.

https://www.youtube.com/watch?v=E1M3hNlhQCg

https://wiki.openjdk.java.net/display/shenandoah/Main

http://openjdk.java.net/projects/shenandoah/

#Java
#JVM
#JDK

Трансляция из главного зала конференции Highload++ 2018 в Москве, Сколково.

https://youtube.com/watch?v=dHSCBCyrcP4 - День первый, 8 ноября

https://youtube.com/watch?v=hkcOmILykas - День второй, 9 ноября

http://www.highload.ru/moscow/2018

@HighLoadTalks

@HighLoadChannel

Ссылки на посты о предыдущих конференциях:
https://t.me/technologique/1136
https://t.me/technologique/1137
https://t.me/technologique/583

The History of Unix

История Unix глазами Роба Пайка.
Карьера, рабочая практика и инженерные труды Роба весьма интересны и обширны — Роб был сотрудником Bell Labs, инженером команды Unix, разработчиком ОС Plan 9 и Inferno, соавтором формата кодирования символов UTF-8 и языка программирования Limbo, автором языка Newsqueak, а также многих других интересных проектов, и ныне он автор языка Sawzall и соавтор языка Go в Google.

https://www.youtube.com/watch?v=_2NI6t2r_Hs

#Unix

Go 2 Draft

Роб Пайк о черновике будущего релиза Go 2 и будущих возможностях языка для уменьшения шаблонного (boilerplate) кода - внедрении параметрически полиморфных обобщённых типов (дженериков) на базе механизма контрактов, а также внедрении механизма обработки ошибок на базе function scopes и namespaces модулей с помощью ключевого слова check.

https://www.youtube.com/watch?v=RIvL2ONhFBI

https://blog.golang.org/go2draft
https://blog.golang.org/toward-go2

#Go
#Golang

The searching for truth is brings us around in a Möbius strip, with a wonderful contradiction of interpretations.

Система типов языка Rust - его главное преимущество и его главный недостаток.

Модель безопасности и гарантий, которую предлагает компилятор Rust - неуниверсальна и ей не хватает достаточной гибкости для применения на практике.
Одна модель статического контроля для всего, для всех задач, а программы и задачи все индивидуальны, и не всё возможно реализовать следуя предложенной модели безопасности, чтобы эта модель не стала ограничением, т.е. модель безопасности не идеальна, поэтому существует unsafe надмножество языка Rust.

Эта модель - affine types for lifetimes and immutable borrows - математическое доказательство существования гипотетической возможности безопасного исполнения программ в существующей архитектуре общей памяти для кода и данных, разделенных на стэк и кучу, value types (off-heap data types) и reference types (pointers).

Модель была описана и разработана Грейдоном Хоаром на языке ML в виде доказательства правил инвариантов и далее была реализована на OCaml (на базе генератора анализаторов camlp4) в виде компилятора программ, написанных на DSL языке для этих целей, которым и стал впоследствии Rust.

Язык Rust вводит подмножество безопасного языка, на котором можно писать безопасно следуя правилам модели, при этом модель ограничивает и сужает множество программ которые возможно реализовать, а за пределами этого множества остаётся очень много решений задач и кода программ для которых нужны статические гарантии безопасности, но Rust их не обеспечивает, потому что модель ограничена и не покрывает, не моделирует это множество задач и программ, поэтому в них прибегают к unsafe, хотя в них тоже необходимы статические гарантии безопасности.

https://blog.1aim.com/2018/10/finding-and-fixing-memory-leaks-in-a-hyper-application-or-how-i-learned-to-stop-worrying-and-love-the-allocator/

When .into_future() is called on the downcasted error, the leak occurs. Maybe a quick use of cargo-geiger (https://github.com/anderejd/cargo-geiger) will show us a single unsafe function that’s causing the leak?

"My God it’s full of unsafe code!" I exclaim, debugging our monolithic application. Digging through all that is unlikely to be our solution.

Но сколько бы разработчики языка ни старались сужать окно unsafe возможностей, а модель гарантий при верификации программы расширять, всё равно останутся use-cases которые не будут покрыты ограничениями системы типов и не будут входить в рамки модели доказательств для верификации программы.

#Rust

Модель системы контроля lifetimes/immutability, borrow/ownership checker в системе типов, обеспечиваемой компилятором, остаётся несовершенной, главным образом из-за stack-centric/stack-allocated модели гарантий безопасности памяти, которая вводит жёсткие ограничения и на heap-allocated data structures, и ставит управление памятью и работу с данными в куче в жёсткой зависимости от управления памятью кадров стэков вызовов, хранящих контекст, переменные и объекты памяти в рамках их lifetimes и в рамках scopes/namespaces подпрограмм/функций.
Каждая последующая доработка модели гарантий безопасности памяти (через RFC и комитетные решения) вводит дополнительные ограничения и уровни сложности в саму модель гарантий, в систему типов, в синтаксис и семантику языка.

https://medium.com/@GolDDranks/things-rust-doesnt-let-you-do-draft-f596a3c740a5

Lifetimes in Rust are essentially subject to stack discipline. An “outlives” relationship between two lifetimes means that the longer-living one originates from an outer scope or an earlier (shallower) stack frame.

This principle works wonderfully with the call stack. But it’s too restrictive with the heap. The lifetimes are not aware of the heap — there can be references to the heap, but they act as if the heap would be just a nice extension to the stack that allows dynamically sized allocations. The lifetime of a reference to a heap allocation is still constrained by the stack frame where the lifetime of the reference originated from.

Из-за столь жёстких ограничений вокруг модели (affine types for lifetimes and immutable borrows model) уже построено множество паттернов её использования для удовлетворения системы типов (https://t.me/libmustdie/1364).

http://smallcultfollowing.com/babysteps/blog/2018/11/01/after-nll-interprocedural-conflicts/

http://smallcultfollowing.com/babysteps/blog/2018/11/10/after-nll-moving-from-borrowed-data-and-the-sentinel-pattern/

Сам я больше предпочёл бы решать где мне нужны повышенные гарантии безопасности при помощи аннотаций самостоятельно. В этом плане D и Nim более гибкие языки - они дают все необходимые средства не только для автоматического (RAII), но и для ручного управления выделением и освобождением памяти, гарантиями безопасности памяти, указателей, потоков, и иммутабельности данных, но при этом возлагают ответственность за безопасность больше на самого программиста, чем на компилятор и систему типов.

При этом санитайзеры (https://github.com/google/sanitizers) и статический анализ в C++ например оказываются более простым решением, чем использование Rust как альтернативы.

По вопросу возможного будущего новых языков программирования есть весьма интересное мнение Андрея Александреску, соавтора языка D, автора его стандартной библиотеки (Phobos), программиста с огромным опытом разработки на C++:

https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why

https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Andrei-Alexandrescu

Во многом Андрей Александреску прав - как минимум в том, что Rust как боди-билдеры, которые пропускали дни ног, сконцентрировавшись на прокачке только торса (https://twitter.com/t_nation/status/521795722233270272).

Эта весьма забавная аллегория, возможно понятная только тем, кто достаточно хорошо успел разобраться в Rust, очень точно характеризует язык и его систему типов.

Rust имеет явный асимметричный перекос в дизайне языка в сторону концентрации абсолютно всех языковых стредств на безопасном управлении памятью посредством контроля иммутабельности памяти через владения и заимствования указателей, контроль времени жизни (lifetimes ) областей видимости (scopes) контекста исполнения функций, завязанного на стэк вызова функции, хранящий её контекст, все переменные и объекты памяти, что в свою очередь необходимо для прецизионного автоматического управления памятью при помощи деструкторной техники освобождения ресурсов (RAII) без использования традиционной автоматической сборки мусора (GC, трассирующего или с подсчётом ссылок).

I found that my thinking was dominated by memory management and consequently it was difficult to concentrate on what I was actually trying to program!

Неидеальность модели управления и обеспечения безопасности памяти, отсутствие гибкости и возможности адаптации модели, при применения её к множеству классов задач, ведёт к неудобствам, а иногда и невозможности в использовании языка и его неуниверсальности.

И тем не менее многие из нас ведомые евангелизмом корпораций (которые конечно же формируют экосистему из нас в своих коммерческих целях - никак иначе) подвержены "парадоксу Blub" (Blub paradox), описанную Полом Грэмом в его статье "Beating the Averages" (http://www.paulgraham.com/avg.html). Понятие парадокса Blub в статье и использовалось Полом Грэмом как показательная ситуация сложности определения наилучшего языка программирования, в особенности незнакомого и сответственно бессмысленности дискуссий на эту тему. Более того сравнивать языки по отдельным возможностям чаще вообще некорректно.
Каждый из нас оказывался в подобной ловушке, когда выбирал удобный для себя или проекта язык, а после, когда вновь вставал вопрос выбора боялся обжечься о что-то более новое или более сложное. Отсюда произрастают корни многих holly wars за те или иные языки.
О данном парадоксе в применении к языку Rust есть две очень классные статьи Джонатана Тёрнера, бывшего разработчика Rust в Mozilla:

https://www.jonathanturner.org/2016/01/rust-and-blub-paradox.html

http://www.jonathanturner.org/2016/01/rethinking-the-blub-paradox.html


Ссылки на статьи и материалы по теме:

https://medium.com/@GolDDranks/things-rust-doesnt-let-you-do-draft-f596a3c740a5

https://github.com/anderejd/cargo-geiger

https://github.com/icefoxen/cargo-osha

https://blog.1aim.com/2018/10/finding-and-fixing-memory-leaks-in-a-hyper-application-or-how-i-learned-to-stop-worrying-and-love-the-allocator/

https://www.tockos.org/blog/2017/crates-are-not-safe/

https://www.reddit.com/r/rust/comments/9926jq/cve20181000657_buffer_overflow_in_vecdequereserve/

https://medium.com/@shnatsel/how-rusts-standard-library-was-vulnerable-for-years-and-nobody-noticed-aebf0503c3d6

https://medium.com/@shnatsel/auditing-popular-rust-crates-how-a-one-line-unsafe-has-nearly-ruined-everything-fab2d837ebb1

https://words.steveklabnik.com/you-can-t-turn-off-the-borrow-checker-in-rust

https://raphlinus.github.io/programming/rust/2018/08/17/undefined-behavior.html

https://medium.com/message/everything-is-broken-81e5f33a24e1

Как начинался проект языка Rust восемь лет назад.

http://venge.net/graydon/talks/intro-talk-2.pdf

Смотрим, сравниваем концепции и сниппеты кода, и делаем выводы самостоятельно, ведь будущее уже наступило!

Вебинары по возможностям Kotlin с командой разработки JetBrains - 5 и 12 декабря

Андрей Бреслав ответит на интересующие вопросы о релизе Kotlin 1.3 и в целом о проекте языка Kotlin.
Роман Елизаров расскажет о многопоточности и асинхронном IO на базе сопрограмм.
Николай Иготти расскажет о Kotlin/Native и кросс-платформенной разработке на языке Kotlin.

https://blog.jetbrains.com/kotlin/2018/11/join-kotlin-1-3-webinars/

https://twitter.com/kotlin/status/1065938092090109952

https://www.youtube.com/user/JetBrainsTV

#Kotlin

Новый трейлер и анонс фильма "Software Wars" Кита Кёртиса, спустя пять лет после первого анонса.
Сейчас этот фильм будет даже более актуален, чем ранее.
Ждём с нетерпением - релиз окончательного монтажа фильма намечен на конец этого года.

https://youtu.be/4dZELuZl4wk

http://keithcu.com/wordpress/?page_id=407

Посты по теме:
https://t.me/technologique/577
https://t.me/technologique/43

AzureDay Moscow 2018

10 декабря в Москве пройдёт конференция AzureDay Moscow 2018 для разработчиков, DevOps инженеров и всех интересующихся облачными рещениями и инфраструктурой Microsoft Azure. Мероприятие проводит сообщество Microsoft MVP (Most Valuable Professionals), поэтому всю самую свежую и полезную информацию о возможностях Azure, перспективах развития облачной платформы и её применении можно будет получить из первых уст от профессионалов использующих инфраструктуру Azure Cloud ежедневно для разработки бизнес решений.

https://www.youtube.com/watch?v=-nWMck_qox0

Регистрируйтесь для посещения конференции (количество участников ограничено) или для просмотра онлайн трансляции мероприятия.

http://azureday.ru

https://habr.com/company/microsoft/blog/431742/

#Azure
#Cloud
#DevOps

Kotlin 1.3 Webinars

Вебинар 5 декабря:
https://www.youtube.com/watch?v=FAhR_sqlUy4

Андрей Бреслав о проекте Kotlin и релизе версии 1.3, Q&A сессия
https://www.youtube.com/watch?v=ewhjnz5AHmw

Роман Елизаров о сопрограммах и реализации средств многопоточности в Kotlin
https://www.youtube.com/watch?v=9HUFo4WyDPI

Вебинар 12 декабря:
Николай Иготти о возможностях Kotlin/Native для кросс-платформенной разработки (multi-platform projects, MPP)
https://www.youtube.com/watch?v=k4G6AAR0Fds

Специально для читателей канала интересующихся концепциями языков программирования я воспользовался возможностью задать вопросы авторам Kotlin и сформировал их список:

https://gist.github.com/andrcmdr/d857617efdfb4ca4520c0cee4ad2f497

https://twitter.com/andrcmdr/status/1070087879576248321

Некоторые вопросы получились весьма комплексными, но все (в разной степени) были освещены в ходе Q&A сессий вопросов и ответов данных двух вебинаров.
Надеюсь такой формат станет традицией, т.к. помогает разобраться в возможностях новых релизов Kotlin, а авторам получить отклик в виде вопросов от сообщества.

#Kotlin

Kotlin 1.3 Coroutines Webinar

https://www.youtube.com/watch?v=9HUFo4WyDPI

В первом вебинаре о средствах многопоточности в Kotlin Роман Елизаров дал на мой взгляд наиболее прозрачное объяснение механизма работы сопрограмм не только в Kotlin, но и общего принципа их реализации во многих других языках программирования - сопрограммы скрывают более примитивные и менее выразительные механизмы колбэков, продолжений и futures/promises очередей, на базе которых они сами построены, но дают при этом большую выразительность абстракций для асинхронного кода.

Механизм передачи продолжений на базе колбэков (continuation passing style, CPS) есть языке Scheme (call/cc, call with current continuation), диалекте Lisp, и подобный подход был привнесён и применён в Kotlin.
Но даже в таком классическом труде как книга SICP (Structure and Interpretation of Computer Programs, Структура и интерпретация компьютерных программ, за авторством Гарольда Абельсона, Джеральда Джей Сассмана и Джули Сассман) использующей язык Scheme для изложения фундаментальных концепций computer science для создания компиляторов языков программирования, в разделе про механизмы стримов, содержится менее простое объяснение механизмов многопоточности и асинхронного исполнения кода на базе сопрограмм:

https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book-Z-H-23.html#%_sec_3.4.2

https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book-Z-H-24.html#%_sec_3.5.1

https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book-Z-H-24.html#%_sec_3.5.4

Также отдельно про продолжения из индекса определений в книге:

https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book-Z-H-28.html#%_idx_4984

https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book-Z-H-28.html#%_idx_5000

https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book-Z-H-32.html#%_idx_5700


#Kotlin