Я вроде бы нигде не заикался ни про один стандарт. Я под core имею ввиду не то, что в каком-то стандарте обозвано core. А ядро Форта - некий минимальный набор слов, который по неизбежности оказался общим для всех Фортов. Своего рода метафизическую квинтессенцию и дух Форта. Причем даже мелкие различия в именовании слов типа -DUP и ?DUP этого ядра не меняют. Ибо смысл при этом одинаков. А вот всякие FIND и PARSE к ядру не относятся ибо неизбежности одинакового смысла для нет, лишь похожего. Я твой Форт первый день вижу. Ну тогда так должно быть еще оптимальнее :

Вот приведены 3 форт-системы, в которых нет слова ?DUP в ядре. Видимо форт уже не торт


А что EXIT не входит в метафизическую квинтессенцию Форта?

Не знаю, но мне ?DUP никогда лишним в системе не казался. (т.к. это слово легко применяемое и понимаемое)

Только потому, что : ?DUP DUP IF DUP THEN ; Где надо, оно появляется, и как-то традиционно сложилось, что в ядро не попало.


Как правило, DO LOOP полезен для обработки больших массивов, в отличие от BEGIN WHILE REPEAT, для которого характерно выполнение с проверкой какого-то локального условия. А вот DO LOOP - это про мегабайтные массивы с i-м элементом. Там даже пустой цикл заметен по времени выполнения.

Так я думал не об EXIT-е, а как вставить машинный JUMP на точку сразу за +LOOP. Потом надоело разбираться как это сделать и я подумал, что раз адрес куда надо прыгнуть есть на стеке, то сделаем JUMP RET-ом. Вставил RET, и не получилось. Потом обнаружил, что если обрамить RET, квадратными скобками, то компилируется то, что нужно. Потом подумал, что кажется это в точности EXIT и кажется я забыл один DROP и тут-же удалил свое сообщение об [ RET, ] чтобы обдумать. Ты уже на удаленное сообщение отвечал и теперь ерничаешь. А меж тем я на твой Форт внимание обратил и две ошибки в твоем Форте нашел, а кто еще так сделал и по сему можно было бы и не ерничать. Я же по поводу твоих ошибок не ерничал.

Кстати если -7D3 word not found то уже пиши какое именно word not found (эха-то вводимых из файла строк нет), а то приходится вывод диагностических сообщений по тексту раскидывать чтобы обнаружить в какой именно строчке и какое именно слово not found. Особенно в интерпретируемом тексте когда latest word подсказывает, что все было в порядке страницы три текста выше. Форт итак спартанская среда, а у тебя отладка спартанская в квадрате.?DUP по жизни удаляет ветку ELSE DROP THEN которая без него возникает постоянно. В этом его призвание.

Хотите верьте, хотите нет, но только сейчас в голову пришло, как это получше сделать, не трогая транслятор М-да.

Насчёт спартанской отладки в квадрате не черезчур ли?

Для отладки еще хорошо строки считать, причем не просто глобальным инкрементом, а для каждого файла. Но я это не в самом Кварке у себя делал, а с учетом подключения чего-то внешнего. Потому что вот будет ошибка, пусть даже с выводом неправильного слова, а где это слово искать? По всем файлам? Удобнее, когда имя файла и номер строки с ошибкой можно хотя бы достать из транслятора внешней программой.

В Нове с этим проблемы с подобной отладкой.
В СПФ это есть, но подозреваю, что там всё завязано с трансляцией файлов.

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

Впрочем, ошибки позиционируются с точностью до последнего определённого слова. Думаю, что с выводом слова породившего исключение это будет достаточно.
Ну или переопределить слово TRANSLATE-FILE, благо это вектор

Как локализовать ошибку - интересный вопрос. Если ориентироваться только на слово, вызвавшее ошибку, то можно свалиться либо в "ошибку вызвало слово RUN, потому что именно его ввели с консоли, а там уж куда выполнение попало - неизвестно", либо в "ошибка в слове @, потому что именно оно непосредственно выполнялось в момент исключения". Оно где-то логично, что наиболее вероятные кандидаты попасть в исключение - @ и !, когда им неправильно передают адрес. Поэтому хочется-то видеть всю цепочку, от слова, запустившего все, до слова, на котором все упало (и заодно при каких обстоятельствах - сразу, или когда дошли до определенной итерации цикла). Другой вопрос, что отладочную информацию можно просто не успеть достать.

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

Так эта. Если Форт выводит эхо строк, то на какой строке заткнулось видно сразу. Если еще показывает на каком именно слове в строке ошибка, то вообще комфорт, хотя без этого не проблема и обойтись. А у тебя ни того ни другого. Я в исходник слово WORDS вставлял и смотрел вывалило ли список слов или нет. Если выволило - ошибка по тексту выше, если не вывалило по тексту ниже. Потом слово WORDS перемещал вверх или вниз и опять смотрел. Так строку с ошибкой и вычислял. А ошибки-то какие были - оказывается у тебя CHAR+ нет, S>D нет, 2@ нет, 2! нет, D< U< 0< нет, LITERAL нет и даже после подключения ~ER/DOLOOP.F нету J . Вот глядя на текст как ошибку было увидеть ? Нашел проблемную строку, пучишь на нее глаза и непонятно, ну здесь-то что может не нравится ? Приходится дополнительными экспериментами вычислять теперь уже проблемное слово в строке, порой пошинковывая ее на строки и [ WORDS ] между ними вставляя. Ну чем не спартанская отладка в квадрате ?
Тут решения два - или валить в консоль эхо строк исходника, читаемого из файла, или показать проблемное слово. Либо то, либо другое, либо и то и другое. Это вот как я у себя делал. Либо как Хищник предлагает вывести номер проблемной строки.

WORDS это жёстко)
Я использовал связку число и точка т. е. к примеру
Да и вообще при ошибке выдаётся краткая информация:
последнее скомпилированное слово
STATE и BASE возникшие при ошибке.

По остальному конечно,
Слов для работы с числами двойной длины нет поскольку не требовались отчего-то ни разу за последнее время, а так вещь нужная.
С LITERAL ситуёвина интереснее. Слово несколько блеклое что ли... связка [ LIT, ] наглядней.
Соот-но : LITERAL LIT, ; IMMEDIATE
Я уже и не помню почему решил отказаться от этого слова.

Да я заметил. Но если пишешь исходник не для компиляции в EXE, а для немедленной интерпретации, то ниже последнего определяемого слова может быть уйма текста. Там ведь обычно нужные слова наопределяешь, а потом или расписываешь что в процессе интерпретации делать. И если при этом используешь словечко которого нет, то начинается засада найти где грабль.
смотри. Не важно что у тебя каких-то слов нет. Важно чтобы не было препятствия определить нужные слова. А без U< у тебя много чего определить будет невозможно. Или перейти к арифметике еще большей точности. Тут бы D+ и главное без UM* и UM/MOD не обойтись, это слова у которых произведение и делимое двойного размера, вот без них никак. Умножения и деления совсем уж больших чисел через них определять.

У меня тогда вопрос, где вы используете числа такой большой длины? Где 4 гигабайтов не хватает?

Тут вопрос не в том, что чего-то не хватает, а в том, что некоторые вещи нельзя доопределить, потому что нужно или знать внутреннюю структуру, или иметь доступ к вещам, которых на уровне слов Форта просто нет. D+ как раз такое слово, его надо писать на ассемблере, а через + не выразить никак.