По идее, в диссертации упор должен быть на исследовании, а не на реализации. Реализация должна отвечать на какой-то исследовательский вопрос. Просто сделать богатую фичами реализацию языка — это больше инженерная работа, чем научная.
Вот, я копаю сейчас типизацию. Очевидно, что-то по теме статической типизации в конкатенативных языках, с прототипом для Форта — подошло бы.
А вообще, поспрашивай ИИ-агентов, они расскажут.
Чатгпт говорит что одним из направлений могут быть новые возможности:
quotations;
лексические области видимости;
модули;
алгебраические типы данных;
pattern matching;
исключения;
продолжения;
автоматическое управление памятью;
effect handlers;
first-class stacks.
Нужна проверяемая гипотеза:
Уменьшают ли quotations число сложных манипуляций со стеком без заметного роста размера реализации?
Или:
Позволяет ли модульная система независимо компилировать словари, сохраняя характерную для Forth интерактивность?
кажется вокруг окружений тема интересная для исследований?
Проблема что сборщик мусора должен понимать, что на стеке является указателем, а что — обычным числом. Tagged values в принципе решают, но мне кажется это медленно. Отдельные стеки для указателей тоже вариант, но ломают совместимость со старым кодом и, кажется, общепринятыми идиомами, да и неудобно как-то.
Есть еще вариант Stack Maps: форт-система знает, какие позиции стека содержат ссылки. Это требует статического анализа stack effects. Выглядит интересно.
Еще варианты?
А с каким старым кодом ломается совместимость, если речь шла о лексических замыканиях над локальными переменными ("окружением") и других возможностях Лиспа?
И, я говорил не про стек для указателей вообще, а стек для лисповых (или т.п.) объектов.
Отдельные стеки в использовании удобны, потому что они упрощают подготовку параметров (стековые перестановки).
Ага, я сразу не совсем осознал и имел ввиду, что код написанный в старом идиоматичном для форта стиле уже не будет работать. Но думаю это небольшая проблема
Я не смогу положить значение указателя, который менеджится GC на обычный DATA STACK и поэтому мне придется иметь отдельные операции для обычного стека и стека указателей. Слова, которые работают одновременно с указателями на GC-объекты (окружения, замыкания) и обычными значения с DATA STACK будут иметь сложную сигнатуру, составную для каждого из стеков...
Уже есть такие стандартные слова. Например, слово «f!», его стековая диаграмма:
( F: r -- ; S: f-addr -- )
Надо испытывать, чтобы увидеть, будет ли это сложно в использовании.
В этом минус. Тут можно предложить только разнести их по разным пространствам имен.
Подход с лексическими замыканиями подразумевает интенсивное использование локальных переменных. Поэтому, стековые перестановки, наверное, будут меньше нужны.
Кстати, в пределе, если на все параметры ссылаться через локальные переменные, то можно использовать аппликативные выражения (а не конкатенативные), и тогда вообще обойтись без стека. Будет Лисп 🙃
да. У меня есть проект имплементации локальных переменных но пока я до него не дошел, обхожусь стековыми перестановками. Там получается еще и отдельный стек локалов. Возможно есть способы как-то по другому делать это?
Если мы решаем Upwards funarg problem, то стек не подойдет. Каждый фрейм локальных переменных живет своей жизнью в общем дереве, и освобождается через сборку мусора (и/или счетчик ссылок).
Беда подкралась откуда не ждали :)
Итак, у меня есть несколько стеков:
- data
- return
- возможно locals
- catch/throw
- ...
Форт-система кооперативная многозадачная, с переключением в NEXT
Memory Regions под стеки выделяются динамически так как fibers появляются и исчезают в процессе работы системы. Освобожденные регионы переиспользуются.
Я бы хотел при переключении наблюдать состояния стеков. Когда я вижу что стек близок к исчерпанию, я бы хотел переносить стек в более большой Memory Region.
Но (как минимум) data и return стеки могут хранить указатели, которые никак нельзя отличать от integers. А еще есть же absolute address, execution token...
Допустим, я типизирую все значения, путем теггирования (что замедлит работу из-за битовых операций) или путем паралельного Shadow Stack с типами (что увеличит вдвое расходуемую под стеки память).
Технически это дает возможность пересчитывать те указатели, которые не relative и двигать стеки куда мне захочется? Или есть какие-то подводные камни, которые я не учитываю?
Go runtime (по мнению ИИ, подкрепленном ссылками, которые я не проверял) действительно копирует растущие стеки goroutine, затем отдельно корректирует контекст, defer/panic-структуры и указатели внутри кадров по точным pointer maps - то есть это как минимум возможно
Я пока вижу вариант сохранять все такие указатели как специальное значение (-2 например, чтобы не путать с FALSE), которое говорит о том, что нужно сходить в отдельную таблицу, ключом в которой является адрес ячейки стека, а значением - что-то относительное, что позволит получить доступ к самому значению. И это относительное будет переписываться при всех перемещениях стеков и других Memory Region-ов (словарей?) относительно друг друга.
Получается примерно тот же коленкор что мы обсуждали про объекты, управляемые gc..
Наверное, имеется ввиду переполнение, а не исчерпание.
Стек (с содержимым) можно перенести в другую область памяти, если нету ссылок на ячейки стека через их абсолютный адрес. А стек локальных переменных вообще не обязательно переносить. Его можно сделать просто связным списком фреймов.
Стандартные программы не могут получать адреса ячеек стека.
Адреса ячеек стеков обычно используются в реализации исключений. Но, вместо адреса вершины можно запоминать текущую глубину стека. Или, корректировать адреса, т.к. список фреймов исключений известен.
Иногда адрес ячейки стека данных (или стека возвратов) передается параметром (например, при вызове внешних функций). Тут можно использовать адрес из фрейма локальных переменных, который остается постоянным (т.к. фрейм мы не переносим).
Но (как минимум) data и return стеки могут хранить указатели, которые никак нельзя отличать от integers. А еще есть же absolute address, execution token...
Это не мешает переносить стек в другую область памяти. Главное, чтобы в неизвестных местах не хранились ссылки на сами ячейки стека.
#forth #implementation
https://t.me/ruforth/18902/19331
☝️ Тегировать адреса можно одним битом.
Shadow stack имеет смысл, если мы хотим динамически проверять согласования типов данных, а не только отличать адреса от других значений. Но это тянет за собой и shadow memory. https://t.me/ruforth/11687/18084
#forth #typesystem #technique