OberonCore

Илья Евгеньевич Ермаков
От динамических средств расширения семантики Компонентного Паскаля — к расширяемому синтаксису
https://youtu.be/v71zsKrF60Y

Йошкин кот! Даже с картинкой специальной!

Создаётся впечатление, что просто Компонентный Паскаль не очень соответствует потребностям Ильи.

Раз речь идёт о внешнем по отношении к программе расширении через дополнения к компилятору, да ещё без попыток сделать особо удобным написание расширений, то, может быть, лучше просто сделать ещё один frontend к компилятору, в котором воплотить все хотелки? В чём преимущество написания отдельных расширений?

Памятуя наши беседы о метапереходах, задам вопрос - не было желания или попыток воплотить токены через рефлексию?

По сути, в первой части доклада речь идёт о статическом описании предметной области (+ константы) через токены, но шире чем просто в референтной модели.

Удобным решением в этом случает мог бы быть расширенный словарь данных, в котором все описания данных и их представление хранятся в одном месте. Не усложняя визуальные средства, для этого можно использовать табличное представление на нескольких связанных табах типа как на картинке ниже. Такой словарь можно записать в файл удобном для парсера формате. Со многим остальным справится препроцессор и парсер.

Здесь можно "срезать" много лишнего кодирования и обеспечить актуальность модели данных,
обращаясь к словарю в запросах к базе данных и константам -> как в примере запроса в этом докладе https://youtu.be/v71zsKrF60Y?t=2415

Мне представляется, что такой словарь мог бы быть и частью решения второй части доклада.

В таком словаре данных можно формировать таблицы БД, связи между ними, представление данных в окошках десктопного приложении, представление в Web и отчётах. Что-то подобное было реализовано для многих ЯП и в т.ч. для Clarion.
Картинка - Скриншот экранной формы словаря данных:
https://i.ytimg.com/vi/RF_6xDxS8Wo/maxresdefault.jpg

Словарь данных с привязкой к редактору и конструктору форм может стать удобным средством как дополнение к IDE BlackBox, которое привлечёт многих разработчиков.

Иван, кажется вы раньше просили автора написать статью о токенах )))
После этого видео, можно опубликовать примеры использования токенов из доклада?

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

Без статьи непонятно, нужна ли статья. Частота упоминания наталкивает на мысль, что тема, видимо, достойна частого упоминания. Но без подробностей создаётся впечатление, что это что-то естественное и проходное. Например, в Java для чего-то подобного используется тип Enum - специальные классы. В них, порой, не хватает наследования и приходится использовать обычные singleton.
Может, за статью сойдёт определение на 1-2 абзаца или сопоставление с похожими образцами из известных источников.

Илья, вот такой вопрос. Токены, это что-то типа хеш-таблицы с записями?

Нет, токен - это просто объект, созданный в куче и доступный через глобальную переменную.

Хеш-таблица возникает только для трансляции из численного перманентного UID в сам токен.

по поводу токенов можно найти информацию в инете. Вы всех заинтересовали оригинальным способом их использования. Насколько помню, на конференции 2018 года в Орле вы упоминали в докладе, что этот способ позволил ускорить работу программы, в т.ч. после загрузки программы, её настройки и пр. вы отключали сборщик мусора.

Можно более подробно об этой схеме работы и её надёжности? Да, и можно тексты примеров ваших токенов из последнего доклада опубликовать?

А что пишут в интернете?
То, что именно так используют объекты-синглтоны - это наверняка. Но называть это токенами, вроде, никто не называл.

А то, что называют токенами, - это обычно нечто из других областей.


Нет, это с токенами не связано. Токены вообще никакого отношения к сборке мусора не имеют, т.к. это глобально доступные объекты, время жизни которых совпадает с временем жизни модуля, в котором они объявлены.

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


В устоявшемся варианте это пойдёт в open-source. Сейчас много всего тянет с собой.

Глобальная переменная - это указатель на хеш-таблицу?

Нет, указатель на информационный объект этого конкретного токена, типа такого:

коллизии - это как недостатки глобальных объектов.
А можно немного рассказать как создать такой пул используемых объектов и как в этом случае корректно отключить, а потом включить сборщик мусора?

А UID генерится у вас на этапе компиляции? или на этапе написания кода?

Нет, это я просил и Дмитрий Викторович. Ещё год назад (а то может и больше уже).

ID токена - как статической сущности - у меня используется 64-битный (UID динамических сущностей требует уже 128 бит для глобальной уникальности).

Старшие 32 бит UID - это Project Id, вычисляемый как хэш от Project Name и определяемый где-то в подсистеме проекта.
Младшие 32 бит UID - это хэш от имени переменной токена (Module.VarName).

Т.е. в BEGIN модуля указываем: KrlTokens.InitTokens(MyProjTypes.projectId) - и все глобальные экспортированные переменные токенов инициализируются (создаются их объекты, генерируются ID, устанавливаются их взаимо-ссылки, кто чьё расширение и т.п.).

Если переменную токена надо переименовать, а ID уже используется перманентно, то просто отдельно в BEGIN модуля прописывается выставление ему закреплённого старого ID.

Я использовал вариант с изменённым ядром, где у Kernel.Type base[15] указывает на расширенную структуру TypeEx, где уже и поддерживаются списки возвращённых объектов, откуда их повторно дёргает NEW. Ну а подавить сборку мусора - просто выставить флаг да и всё.

Однако сразу что-то не подумал, что есть вариант отдельной от ядра реализации: местоположение NewRec и NewArr указывается спец. метками при линковке пускача ББ - и можно просто разместить эту поддержку пулов в отдельном модуле.

Илья, а сейчас вроде в куче есть какое-то повторное использование записей? Я где-то читал, что если запись удаляется сборщиком, то при выделении новой записи такого-же типа, она разместится в старом месте, что уменьшает фрагментацию. Или это не работает в ББ из коробки?

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

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

Другой способ безопасного освобождения: это 128-битные указатели - и уникальность каждого выделенного указателя. Либо аппаратная 128-битность (как у старого Эльбруса), либо техническое поле у каждого указателя типа era/version, которое сверяется с меткой у адресуемого блока (но начала блоков не должны также "гулять", блок должен всегда оставаться блоком).