Даже сравнительно простой мир, такой как ArtifactoryMMO, приподносит не мало неожиданностей. Хотя есть много примеров кода для управления этим миром из Javascript и Python, я выбрал более серьезный язык, расчитывая прикрутить туда какие-нибудь интересные алгоритмы машинного обучения. Но все равно слишком часто, по крайней мере при отладке, приходится отдавать отдельные команды и анализировать что получилось вручную. Несмотря на прекрасный REPL в Julia, один из лучших, что мне доводилось использовать, и для отладки своего кода, и просто как калькулятор, здесь это оказалось не очень удобно. Конечно, есть curl и jq, но по эргономичности он тоже не идеален. Не curl-ом единым, удобный HTTP-клиент встроен, например, в PowerShell. Но мне захотелось чего-то нового и прогрессивного, и я решил посмотреть Nu. Эта статья предназначена, чтобы привлечь к этому shell любителей MMO-игр, и заинтересовать MMO-играми пользователей nu-shell, а если повезет, заинтересовать обоими темами тех, кто раньше про них и не знал.

Одна из самых эзотерических тем в программировании и computer science это продолжения (continuations), ограниченные продолжения (delimited continuations) и continuation-passing style. Я попытаюсь раскрыть эту тему понятным для обычного программиста языком. Предполагается, что обычный программист знаком с понятиями функции/подпрограммы, фрейма вызова (stack frame), а также имеет базовое знания языка Scheme, хотя бы на уровне первых глав SICP.

Язык Prolog создавался для задач иссуственного интеллекта, который сейчас обычно называют "классическим", чтобы не путать с задачами машинного обучения путем подбора большого числа числовых параметров. Важным классом таких задач является моделирование "мира", в котором можно совершать какие-либо действия. Игрушечным примером такого мира является Nani Search. И решают их часто в таком стиле: состояние мира помещается в прологовскую базу данных и все изменения производятся путем удаления и добавления фактов в это хранилище. Но это получается уже не логическое программирование, а самое настоящее императивное! При этом используются худшие практики программирование - глобальное состояние! Мимо этого я пройти не могу!

Но самое плохое в таком подходе не стиль, в конце концов большая часть современного кода императивна, и даже частенько использует, явно или неявно, глобальные переменные. Важно что состоятние мира перестает быть first-order value и пропадает возможность решать задачи в моделируемом мире, для чего и создавался язык Prolog.

Наиболее распространенная модель адресации памяти - плоская, когда у каждого элемента памяти есть глобальный адрес. Но это не единственный способ работы с памятью, в данной статье я хочу рассмотреть одну из альтернатив - сегментную адресаци. Будут расмотрены несколько исторических систем, реализующих этот подход, преимущества сегментной адресации с точки зрения масштабирования и безопастности, а также высказаны гипотезы о причинах, по которым он не прижился (спойлер: буду ругать язык C и операционную систему Unix).

В подавляющем большинстве компьютерных систем для работы с некоторой ячейкой памяти необходимо как-то указать ее адрес, как правило 16-, 32- или 64-разрядное число. Количество бит в адресе часто называют разряностью системы. Часто дополнительно используется механизм "трансляции страниц", который отображает области виртуальной памяти пользовательского приложения в физическую память, которой управляет операционная система. Но в каждый момент времени активна отлько одна "таблица страниц" и с точки зрения приложения (а во многом и с точки зрения ядра ОС) память остается плоской.

Рассмотрим старый процессор Intel 86/88/186. Размер регистров этих процессоров всего 16 бит, что позволяет адресовать всего 64 килобайта памяти. Когда эти микросхемы разрабатывались, такого размера памяти уже не хватало для многих приложений, а 32-разрядные процессора были слишком дороги. Проблему решили добавив в архитекруту сегментные регистры. При обращении к памяти к 16-битному адресу (хранящемуся в реристре общего назначения или прямо в коде команды) прибавлялось значение сегментного регистра, сдвинутое на 4 бита (что тоже самое, умноженное на 16) и полученное значение использовалось как физический адрес. Такой подход позволял адресовать до одного гигабайта памяти. В архитектуре персональных компьтерах IBM PC, созданных на базе этих процессров, часть адресного пространства было зарезервировано для системных нужд, а пользовательским приложениям и ОС было доступно до 640 килобайт. Но не все так просто.

Во многих языках есть специальный механихм для кодогенерации - макросы. Иногда из реализуют на отдельном достаточно примитивном языке, основанном на простой подстановке текста (препроцессоры PL/I и C, m4), но даже в таком варианте удается делать интересные и полезные вещи. Другой популярный вариант - макросы реализуются на том же языке, что и программа, в которой они используются. Такой подход ведет свое начало из Lisp (удобный тем, что формат программ и данных там одинаков), активно применяется в Julia, OCaml(camlp4/5), Scala, Haskell, Rust, а наибольшего развития получил в Nemerle, где макрос может может запускаться как до, так и после проверки и вывода типов, и в последнем варианте иметь доступ к типам.

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

Conditions

julia> immutable X a end

julia> immutable Y a ; b end

julia> @case(Y(X(9),2),  Y(4,3)-> 55, Y(X(k),2)->1+k)
10

Наследование