Структуры для Каллисто-2

Большие перерывы между периодами практики дают мне время продумывать стратегию разработки Каллисто. Хотя сейчас акцент идёт на оптимизацию по скорости, параллельно в язык вносится ряд улучшений — большей частью из Форта.

Изучая ситуацию с Фортом, я наткнулся на такое сокровище — реализацию структур в gforth (англ.):
http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Structure-Usage....

Сам поиск был интересным и могу рассказать, если кому любопытно послушать или почитать. Для экономии вашего времени, выложу здесь результат.

gforth — версия языка Форт, которую с 1992 продвигает австрийский net.personality Anton Ertl. gforth — свободный компилятор под той же GNU GPL v3, что использует Каллисто. Более того, gforth является частью проекта Гну, а сам Антон Эртл активно участвует в международном комитете по стандартизации Форта, упомянут в Руководстве по Каллисто Классик (стр. 6).

Мне понравилось, что структуры gforth лаконичны и поддерживают иерархию (расширение) типов — научный подход из Оберона к тому, что зарубежная индустрия называет «наследование в ООП». Подобный подход поможет, со временем, разработать необходимые структуры данных и реализовать в Каллисто СКМ. Здесь, конечно, очень не хватает проф. Дьяконова (1940–2015), кто разбирался в Форте, любил ПМК и профессионально занимался разработкой СКМ. Это один из недостатков постепенного пути. Пока русский аппаратный и программный инструментарии неторопливо совершенствуются и пробиваются сквозь тернии, ключевые люди, важные для продолжения проекта, уходят из жизни.

Конечно, помимо иерархии типов нужно продумать модульность («инкапсуляцию» на птичьем языке ООП, она же «библиотеки» и «юниты» из менее фундаментальных подходов к программированию). Но это уже другая история.

P.S. До кучи, реализация структур в СПФ сведена к одному слову -- (расширение записей поддерживается):
http://spf.sourceforge.net/docs/intro.ru.html#struct

Comments

Ещё одна реализация структур есть в Форте-2012 (англ.). Она слишком многословна и не поддерживает расширение записей.

Синтаксис СПФ компактней и экономней в реализации. Синтаксис gforth проще для новичков в Форте — владельцев ПМК, кто впервые столкнётся с Фортом в Каллисто. Приятней, когда структуры определяются классическим «struct … end-struct», чем брутальным «0 … CONSTANT».

Ещё один грустный предмет моих раздумий — отсутствие кучи в Каллисто-2. Если её ввести на этом этапе, она сильно увеличит нагрузку на область двоичных (байтовых) регистров, которая всего 4Кб. В Каллисто-2 я в эту крохотную область переношу весь шитый код, включая код транслятора. Там нет стека данных, заголовков и примитивов, но всё же с кучей будет тесновато.

Конечно, если строить Каллисто-2 в микроконтроллере, 14096 байт объединённой памяти программ и двоичных регистров хватило бы и на кучу, и на всё остальное. Примитивы вообще сидели бы внутри камня. Но пока дефицит байтового ОЗУ, все структуры будут статичными. Создавать их можно будет лишь в словаре, то есть без практичной возможности их разрушать, освобождая память в индивидуальном порядке.

Инкапсуляция в ООП ни разу не модульность. Модульность - понятие концептуального уровня, инкапсуляция - логический уровень.

Модульность — последовательная теория из компьютерных наук. Включающая деление программы, взаимодействующей с другим кодом, на интерфейс и реализацию.

Такое деление основано на сокрытии деталей реализации. Возможно, это на вашем языке — «логический уровень».

ООП взяло из компьютерных наук это «сокрытие деталей реализации» (без которого в XXI веке никуда), пришлёпнув внезапно на описание полей записи — назвав получившееся уродство «инкапсуляцией». Оно прижилось, конечно, из-за обратной совместимости Си и C++. Ровно так, как в индустрии приживаются все другие уродства, для совместимости со старым кодом. :-)

Модульность - функциональное понятие, система делится на модули при функциональной декомпозиции. Инкапсуляция - техническое понятие, сокрытие данных на уровне классов. Например, в C# модулем является сборка (assembly). В Си++ нет элементов, имеющих прямое соответствия модулям, нет даже интерфейсов - все это моделируется из подручных средств (библиотеки с заголовочными файлами, чисто абстрактные классы и т.п.).

Технический костыль — нужный лишь, если язык плохо поддерживает модульность.

По теории скрывать данные на уровне классов требуется лишь в том случае, если эти данные являются деталями реализации (могут отличаться в других реализациях). В этом случае тип экспортируется по имени, становясь частью интерфейса без уточнения внутренней структуры записи. Или вообще не экспортируется.

Модули, конечно, можно рассматривать в контексте анализа системы. Но обычно модули имеют самостоятельную ценность. Часто программирование это разработка не полной системы (с нуля под ключ), а одного или нескольких модулей в уже готовую систему. Идеально, если это поддерживается на уровне языка.

Вряд ли у меня получится реализовать модули прямо в Каллисто-2, но я постоянно думаю об этом. Почитываю Вирта и присматриваюсь к реализациям Форта. Подходы к решению многих других задач уже найдены.