ath писал(а):
Victor__v писал(а):
Лично я в МК не разбираюсь, но зато более-менее знаю СПФ (винда), ежели есть какие-то задачи, то буду рад поспособствовать.
Этой осенью может появиться время для работы над второй версией языка. Возникло три вопроса, по которым помощь серьёзно поддержит проект.
1. ALSO/ONLYСейчас в Каллисто старая схема словарей с VOC-LINK , CONTEXT и CURRENT из Баранова и Семёнова (фигФорт и Форт-83). Одна из причин, почему версия 1.0 названа «Классик» — там старая привычная структура словарной статьи.
Ради быстродействия я перейду на хранение хэшей имён (тоже интересно, что посоветуете) в массиве «плавучки» (десятичные регистры МК-161), где 12 разрядов мантиссы и 2 разряда порядка. Эти 12+2 десятичные цифры будут, помимо хэша, хранить адрес поля кода (4 десятичные цифры) и флаги вроде IMMEDIATE.
Насколько я понимаю, надо будет заводить массив из, скажем, 4 wordlist_id. В которых уже по очереди искать слова. Плюс описать манипуляцию этим массивом в словах ALSO и ONLY. Ну и вся тягомотина с созданием этих wordlist’ов. Кстати, сами списки слов будут пересекаться, как в «базовых словарях»? Сами словари останутся или просто списков слов достаточно? Эти wordlist’ы создаются и уничтожаются независимо или есть «список списков»?
По этому пункту интересно выслушать мнение тех, кто такое уже делал или разбирается в реализациях, т.к. я первый раз это буду делать. И творческий вопрос — не получится ли вынести все слова IMMEDIATE в отдельный список, как в colorForth? Тогда я смогу избавиться от флага в массиве имён.
Ещё интересно, какой сервис по поиску слов язык должен предоставить, чтобы было удобно на нём программировать. Чем народ пользуется. Как верхний уровень (где все эти ALSO/ONLY учитываются), так и нижний. Интересны даже имена «потрохов», если такие уже сложились, в стандарте или де факто.
2. postponeИнтересны как реализация, так и любые рассуждения на эту тему. Пока я не очень интуитивно понимаю это решение, хотя знаю, чем оно вызвано.
Сейчас всё в Каллисто завязано на [COMPILE] и др. устаревшие решения. Буду от этого избавляться.
3. CATCH/THROWСамое важное. Хочу до конца разобраться в обработке ошибок — ещё до того, как начну всерьёз кодировать новый транслятор. Сейчас в Каллисто эта часть не так красива.
Интересна как философия исключений, так и способы реализации. Хочется как дать возможность перехватывать ошибки, как и сделать обработку «по умолчанию» дружественной к новичкам.
Ссылки на стандарты, описания этих 5 слов есть. Интересны как ваш опыт, так и если знаете, где эти три вещи хорошо описаны, включая возможные реализации. Если есть подводные камни или удачные решения — тоже интересно, где. Вообще эти три темы заслуживают отдельных статей. Если статьи или книги на эти темы уже кто-то написал, почитаю и обсужу их с удовольствием.
В общих чертах
Пример словарной статьи, минимум на мой взгляд
Хеш слова (16 бит или сколько там в МК)
поле флагов 1 байт
поле кода (тут хранится указатель на начало кода слова)
поле связи (хранит указатель на пред. слово в списке поиска)
Насчёт ухищрений с размерами меньше байта, не знаю. Хранить длину слова флаги и пр. в одном месте может и компактно, но доставать их труднее (OR XOR AND и иже с ними + место для создания этих слов).
Можно сделать стек словарей. Соот-но CONTEXT вершина VOC0 дно. Проще, чем список. Сам применяю такую схему.
Что сложилось:
PARSE PARSE-NAME SFIND CONTEXT CURRENT
всё
Код:
: POSTPONE COMP? PARSE-NAME SFIND IF LIT, ['] COMPILE, COMPILE, ELSE -2003 THROW THEN ; IMMEDIATE
Что рассуждать-то?
По исключениям
идея:
Сохраним указатели важных стеков в стеке возвратов, и там же сохраним значение переменной HANDLER . Пусть эта переменная теперь указывает на вершину стека возвратов. После этого исполняем токен со стека данных. Если дошли до THROW, то оно с пом. переменной HANDLER сбрасывает указатели стеков восстанавливает значение переменной и выходит из кода, если на хводе этого слова число отличное от нуля.
"сделать обработку «по умолчанию» дружественной к новичкам" это как?
В форте с этим этак очень просто. Ничего лишнего.