В общем - если оффтопик - то не ругайте.
Написал я тут интерпретатор-компилятор форт-подобного языка.

Прошу оценить, если конечно у кого есть время и желание.

Исходные тексты (там же - исходники документации): http://www.nedopc.org/nedopc/upload/afort-cl-1.0.6.tar.bz2
Документация в pdf и dvi: http://www.nedopc.org/nedopc/upload/afort-cl-doc-1.0.6.tar.bz2

Синтаксис не фортовский, хотя весьма похож.
Отличия: есть примитивная типизация (строки, массивы, целые - они же - байты и короткие целые, вещественные). команды сравнения работают как со строками, так и с числами. Массивы - динамически изменяемой длины.
Есть возможность посреди откомпилированного слова исполнить любую строку как последовательность команд (в том числе и определить новое слово).

Что там от ФОРТА:
- все слова разделяются пробелами.
- обратная польская запись выражений.
- компиляция "на лету".
- виртуальная форт-машина.

Что там своего:
по языку:
- типизация (целые, вещественные, строки).
- возможность иметь тип - массив байт.
- адреса памяти преравнены к целым.
- сравнение в соответствии с типом (например можно сравнить две строки - поёмёт).

по виртуальной машине:
- абсолютная модульность - дописать новое слово можно очень быстро.
- словари можно подключать-отключать при компиляции очень просто - добавляя-удаляя их из списка соловарей.
- автогенерация документации по словорям.

Язык писался и опробывался НЕ ТОЛЬКО на PC, но и на процессоре с ядром ARM7.

Интересная штука.

А по существу ?

У меня там системозависимых слов - всего ничего: putc, getc, open и close.
Менеджер памяти может быть как системный, так и самописный (есть у меня такой, я его на ARM использовал, но он аппаратно-независим, на 8битках тоже шёл на "ура").

Так что, хотя это всё на GСС писано - может работать практически везде.

По существу для переносимых систем стоит активнее выделять системно-зависимые слои, их бывает аж до трех. Тут надо соблюсти определенный баланс, потому что putc для вывода все-таки маловато, а попытка расширения функциональности может забросить нас в область PC-only. Скажем, позиционирование курсора еще можно добавить, а вот вывод графики уже под вопросом. В плане набора слов тут можно попробовать написать что-то конкретное, и посмотреть, чего именно не хватает. А так получилась классическая виртуальная форт-машина Классическая - в смысле по реализации на ЯВУ стека и командного интерпретатора.

Пункт для обсуждения, который бросился в глаза - "умное" слово variable. А если я ошибусь в записи начального значения, и тип не тот получится?...

Там это так и сделано практически. В корневом каталоге сборки есть файлик: dict.lst
Так вот - в этом файлике - указано, какие именно словари используются для формирования встроенных слов при сборке.
На данный момент - словарь один: stddict (Словарь - подкаталог в каталоге dicts).

Для каждой архитектуры можно создать отдельный дополнительный словарь и дополнить им файл dict.lst.
stddict - это минимальный словарь. Он и привязан к системе по минимуму. Для его сборки достаточно, чтобы были определены POSIX-функции:

fopen() fclose() fputc() fgetc() fgets() malloc(), realloc() и free()

Если же aForth работает на чёмто без признаков OS, то можно эти функции тупо сэмулировать. Например как это сделано на AVR.
Я запускал aForth под писанной мной же многозадачной операционке NEDOPC-ARMOS, так что привязка к PC-ONLY отпадала сразу: http://www.nedopc.org/nedopc/upload/armos-0.11.0.tar.bz2

Более же продвинутые функции привязки к системе лучше сделать в виде отдельных вкомпилируемых по мере необходимости словарей, например:
armos.dict
avr.dict
linux.dict - поместить словари в каталог dicts и указывать список нужных в файле dict.lst



Почему под вопросом ? сделать отдельные словари опять же. загляни в каталог stddict - там помоему всё прозрачно организовано. Скажем - отдельно словарь terminal.dict - для курсора и цверов на терминале и отдельно - graph.dict

Тогда конфигурирование системы для конкретного проца или ОС сведётся к указанию в dict.lst - какие словари использовать. Ну и вместо make написать, например - make CROSS=arm-linux-



Да - если ошибёшься - не тот тип будет.

0 variable A - целая переменная A
0.0 variable A - вещественная переменная A
"" variable A - строка A

Можно синтезировать слова и переменные "на лету":



В массивах можно перемешивать целые разных типов (байты, короткие, целые)



В архиве с докой - примеров есть ещё не мало.

Массивы можно объединять:

{ "Ёжик " } array A
{ "в " } array B
{ "тумане" } array C

{ A B C } array D

Массив D содержит 3 строки друг за другом:
( Ёжик 0в 0тумане0 ) - 0 - это символ '\0'

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

Тут вообще получается RunTime Type Inference... оно не то чтобы не нужно, просто представляет собой альтернативу. Более сложные проблемы начинаются, когда требуются операции по приведению типов или арифметика указателей.

Хм. А какая проблема ? Перед сборкой компилятора просто не указываешь словарь graph - и всё. Соответственно будут отсутствовать все слова, связанные с графикой.
Но какой дурень будет запускать приложения с графикой на платформе без графики ? Так что проблемы - нет как таковой или я чего-то не понимаю.



Сейчас сделано так:

1. Тип переменной - будучи один раз задан при создании переменной - не меняется!
2. Тип значения, сохраняемого в переменной - ВСЕГДА приводится к типу переменной.
3. Указатель ПОЛНОСТЬЮ равнозначен целому. Фактически в языке нет различий между указателем и целым. Так что хоть умножай их хоть складывай.

Не сделано пока:
4. Ещё не сделаны слова принудительного приведения типов.
5. Определение типа значения на стеке.

Вообче - от роду системе aForth- 3 недели.
Да и в доке у меня немало написано - с примерами.

Хищник, автор сделал очень интересную работу, разве нет?

Речь идет о "голубой мечте" - наборе систем, которые будут очень лояльными по отношению к прикладным программам. Так-то понятно, что от набора библиотек будет зависеть возможность доступа к той или иной аппаратуре.

В принципе, такое делается тэгами, которые заводятся параллельно стеку данных.


Очень.

принудительное приведение типов сделать, конечно, прийдётся... судя по тому, что я понял в замысле автораИМХО

См. Юникс-путь. Каждая программка - делает чтото одно, но хорошо. Если это программа закачаки сайтов, то это ПРОГРАММА ЗАКАЧКИ САЙТОВ (например wget). А если это "графическая морда" ПРОГРАММЫ ЗАКАЧКИ САЙТОВ - то это ГРАФИЧЕСКАЯ МОРДА.
При этом сам wget работает хоть где, а "графическая морда" - разумеется только там, где есть графика.

Помоему этот подход - не зависит от системы. И тем более языка.

Виндоыс-программы в том и проигрывают часто, что каждая из них стремиться стать СУПЕР-МЕГА-КОМБАЙНОМ. То есть - если это программа закачки файлов, то в ней и графморда и просмотрщик мультиков и стиральная машинка. Причём - все встроенное и неизменяемое. Такой подход - мало того, что плодит глюки, так их ещё и фиг отловишь.

Но ведь путь Forth - именно аналогичен присловутому ЮниксВэй. Каждое слово отдельная маленькая чётко определённая функция. И если ктото перемешал неразделимо в какомто мегаслове слова как закачки файлов, так и вывда какойто графики - то он сам себе злющий буратинА и сам пусть с этим мучается, а не требует, чтобы система на AVR, спрятанная в маленькой кладовке, понимала слова для работы мега-3Д-акселлератором.



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

Как оно хранится:
- целые, вещественные константы - хранятся прямо во втором слове.
- строки-константы - в виде адреса-указателя на строку.
- все слова (переменные, массивы, процедура) - хранятся в виде номера слова.

Так что надо просто посмотреть - что на стеке и выдать код типа (целое) на стек. И накаких параллельных тегов для основных типов

Вот прямо сегодня пропишу слова:
istype - снимает значение со стека и возвращает его тип
int-type real-type str-type array-type - возвращают константы - коды соответствующих типов.

тогда можно писать типозависимый код типа
( На стеке нечто хз-какого типа )
: type-test
istype
dup int-type =
if
"На стеке целое" . CR
endif
dup real-type =
if
"На стеке вещественное" . CR
endif
dup str-type =
if
"На стеке строка" . CR
endif
drop
;

Плюс вытащу в виде слова процедуру принудительногго приведения типа
typecastto.

Например:
int-type typecastto - приведёт вершину стека к целому (если строка - вылетим по ошибке)

Далее - надо процедуру проверки - имеется ли такое слово:
"dup" isword ( вернёт на стек 1 - слово dup имеется )
"rrrr" isword ( вернёт на стек 0 - слова rrr не имеется в словаре )

Ну и сделать процедуру удаления всех слов, начиная с указанного и определённых после него Не сделал я ещё этого !!! Забыл.

ну вот и результат работы с типами:

В этом же разделе есть мой Quark-Forth, сделанный в таком стиле
Речь немножко не об этом. Если мы уже двинулись в сторону мультиплатформенности, причем не диаметрально противоположной, то неплохо было бы сделать так, чтобы действительные различия были вынесены в отдельный слой. Иначе нам под каждую платформу и под каждый стиль придется писать свою программу, а из-за какого-нибудь "очень полезного" вызова WinAPI этот же модуль не пойдет на ARM. Хотя ARM сам по себе не такая уж слабая платформа, и вполне можно иметь некий репозиторий модулей, реализующих разные алгоритмы (скажем, сортировка массивов или поиск пути), и одинаково успешно транслирующихся под самые разные платформы. Как сегодня часто бывает, сегодня PC, завтра попросили то же самое в коробочке под ARM, а послезавтра в ПЛИС упаковали со всей периферией. Что же теперь, софт переписывать?

В принципе, разновидность тэга.


А вообще интересный подход, welcome в нашу форумную компанию!

Ну вот - добавил isword.
Версия с исправлениями и дока :

http://www.nedopc.org/nedopc/upload/afort-cl-1.0.8.tar.bz2

http://www.nedopc.org/nedopc/upload/afort-cl-doc-1.0.8.tar.bz2