Очень сложный вопрос

Пожалуй, от него зависит судьба FORTH
 
+
-
edit
 

Gudleifr

втянувшийся

В любой FORTH-системе можно выделить 4 вида данных:
1. ПОТОК - FORTH-данные в текстово-файловой форме, читаемые интерпретатором и переводимые им во внутреннее представление.
2. СЛОВАРЬ - долговременная память, хранилище смыслов слов.
3. СТЕК - кратковременная память - служебная память интерпретатора и память универсального вычислителя.
4. ЗНАЧЕНИЕ - единица информации, передаваемая между ПОТОКОМ и СЛОВАРЕМ, при передаче между ими и СТЕКОМ существует, скорее, в ограниченной форме.
Это не обсуждается...

Вопрос в следующем: должна ли существовать некая "единица информации", которая служит единым "атомом" для построения всех 4-х видов, или, наоборот, все четыре типа должны быть полностью ортогональны, и речь должна идти не о преобразовании информации из одного вида в другой, а об обмене некими сигналами, информационная интерпретация которых полностью определяется своеобразием этих видов?
 30.030.0
RU Balancer #01.07.2014 02:21  @Gudleifr#28.06.2014 23:27
+
-
edit
 

Balancer

администратор
★★★★★
Я, вообще не понимаю, как можно свести к общей сущности поток и стек, например.
 35.0.1916.15335.0.1916.153
RU Gudleifr #01.07.2014 13:02  @Balancer#01.07.2014 02:21
+
-
edit
 

Gudleifr

втянувшийся

Balancer> Я, вообще не понимаю, как можно свести к общей сущности поток и стек, например.

См. например упоминавшуюся работу Дейкстры 62-го года.
Или старый учебный интерпретатор - Trac (см. в "Этюдах..." Уэзерелла).
СТЕК в этих системах представляет достаточно полное отражение ПОТОКА.
 30.030.0
+
-
edit
 

Gudleifr

втянувшийся

Пока пришел к следующему: FORTH, вообще не должен заморачиваться "типами данных". Есть только один тип - "действие". Данные в этом смысле - лишь внутренняя подробность реализации процедуры.
В случае, если требуется синхронизация по данным двух и более процедур возможны варианты:
1. Вы что-то делаете неправильно.
2. Нужен интерфейсный компонент (см. TF Броуди).
3. Данные передаются как адрес процедуры, их выдающей.

Например, в результате распознавания ПОТОКА я получаю ЗНАЧЕНИЕ, тип которого зависит от того, что распозналось: на стеке - адрес слова (если распознали слово) или значение (если распознали число), в словаре - само слово/число (если его не стерли в процессе распознавания), в переменных - флаг немедленного исполнения (для слова), положение десятичной точки (для числа)...
В случае слова все просто, настолько, что флаг немедленного исполнения не запихивается в переменную, а немедленно используется для ветвления.
А вот, в случае литерала, сложнее. Если число можно оставить на СТЕКЕ - ладно (оно уже и так там). А если его надо скомпилировать (передать в СЛОВАРЬ). Нужно анализировать ЗНАЧЕНИЕ, чтобы выбрать тип компилятора. Так, может, проще при распознавании передавать не составное значение, а слово, способное скомпилироваться само и это значение скомпилировать?
Сложность здесь только в том, что легко впасть в грех избыточной структурности/объектности и создать такой "конструктор слов", по сравнению с которым анализ значения будет меньшим злом, несмотря на потребность его переписывать для включения новых типов литералов.
 30.030.0

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru