-
![[image]](https://www.balancer.ru/cache/uploads/images/1247/128x128-crop/1247561-thinking-forth.jpg)
Опрос: к какому месту FORTH цеплять драйвера?
На кошачьем форуме не смоглиТеги:
Gudleifr
Итак, на входе - обычный FORTH, не имеющий на борту ничего, кроме того, что необходимо для его работы (саморазвития). Нам надо расширить его некоторыми свойствами операционной системы - взаимодействием с некими устройствами, многозадачностью и прочим...
Какое направление предпочесть?
1. Создавать лексиконы наподобие Си-библиотек?
Появляется новое устройство - пишем новый лексикон (особый словарь), и все. Например, определяем слова ввода-вывода в порты, опроса семафоров и т.д. Комбинируем их в высокоуровневые слова типа "вкл/выкл".
Плюс - можно подключить что угодно.
Минус - теряется преимущество FORTH-подхода, программа становится практически неотличимой от написанной на Си.
2. Прятать внутрь интерпретатора?
Закапываем всю машинерию вглубь интерпретатора. Пользователь даже не знает, что FORTH где-то что-то химичит.
Например, так обеспечивается работа с FORTH-консолью в графических ОС и реализуется классическая многопользовательность путем переключения пользовательских областей.
Плюс - FORTH-программы просты и стандартны.
Минус - теряется способность программиста получить легкий доступ к внутренностям системы.
3. Усложнять интерпретатор?
Расширяем классический интерпретатор не свойственными ему инструментами.
Дополнительные Циклы Управления, включение новых хранилищ данных, процедур их итерпретации...
Например, целевая компиляция, заменяющая стандартную интерпретацию реакцией на определенный ввод пользователя.
Плюс - идеально подходит для изготовления нужного проблемно-ориентированного языка.
Минус - FORTH перестает быть стандартным.
4. Использовать более одного интерпретатора?
Объединить несколько FORTH-систем вместе.
Например, у меня в FOBOS есть две форт-системы, объединенные общим словарем: одна заполняет словарь необходимыми для примера определениями, другая обрабатывает Win-сообщения примера.
Плюс - каждая из систем остается простой.
Минус - взаимопроникновение нескольких FORTH-систем совершенно не проработано.
Какое направление предпочесть?
1. Создавать лексиконы наподобие Си-библиотек?
Появляется новое устройство - пишем новый лексикон (особый словарь), и все. Например, определяем слова ввода-вывода в порты, опроса семафоров и т.д. Комбинируем их в высокоуровневые слова типа "вкл/выкл".
Плюс - можно подключить что угодно.
Минус - теряется преимущество FORTH-подхода, программа становится практически неотличимой от написанной на Си.
2. Прятать внутрь интерпретатора?
Закапываем всю машинерию вглубь интерпретатора. Пользователь даже не знает, что FORTH где-то что-то химичит.
Например, так обеспечивается работа с FORTH-консолью в графических ОС и реализуется классическая многопользовательность путем переключения пользовательских областей.
Плюс - FORTH-программы просты и стандартны.
Минус - теряется способность программиста получить легкий доступ к внутренностям системы.
3. Усложнять интерпретатор?
Расширяем классический интерпретатор не свойственными ему инструментами.
Дополнительные Циклы Управления, включение новых хранилищ данных, процедур их итерпретации...
Например, целевая компиляция, заменяющая стандартную интерпретацию реакцией на определенный ввод пользователя.
Плюс - идеально подходит для изготовления нужного проблемно-ориентированного языка.
Минус - FORTH перестает быть стандартным.
4. Использовать более одного интерпретатора?
Объединить несколько FORTH-систем вместе.
Например, у меня в FOBOS есть две форт-системы, объединенные общим словарем: одна заполняет словарь необходимыми для примера определениями, другая обрабатывает Win-сообщения примера.
Плюс - каждая из систем остается простой.
Минус - взаимопроникновение нескольких FORTH-систем совершенно не проработано.
инфо
инструменты
mak44
новичок
Gudleifr> Какое направление предпочесть?
Что-то я не улавливаю суть проблемы. Заранее определяться с направлениями
нужно только если эти направления друг-другу противоречат.
Gudleifr> 1. Создавать лексиконы наподобие Си-библиотек?
По моему, лексиконы и библиотеки - это разные категории.
Gudleifr> Минус - теряется преимущество FORTH-подхода, программа становится практически неотличимой от написанной на Си.
Что за преимущество FORTH-подхода?
Gudleifr> 2. Прятать внутрь интерпретатора?
Форт-интерпретатор должен только передавать управление на слова разделенные
пробелом поданные ему на вход. В это суть Форта.
Gudleifr> Например, так обеспечивается работа с FORTH-консолью в графических ОС и реализуется классическая многопользовательность путем переключения пользовательских областей.
Взаимодействие с консолью осуществляется по средствам процедур ввода/вывода.
Какое отношение к этому имеет интерпретатор?
Gudleifr> Плюс - FORTH-программы просты и стандартны.
Если форт-интерпретатор нестандартный то и сам Форт стандартный.
Gudleifr> 4. Использовать более одного интерпретатора?
Gudleifr> Например, у меня в FOBOS есть две форт-системы, объединенные общим словарем: одна заполняет словарь необходимыми для примера определениями, другая обрабатывает Win-сообщения примера.
У тебя Win-сообщения обрабатывает форт-интерпретатор?
Тогда, Win должен генерить форт исходники.
Что-то я не улавливаю суть проблемы. Заранее определяться с направлениями
нужно только если эти направления друг-другу противоречат.
Gudleifr> 1. Создавать лексиконы наподобие Си-библиотек?
По моему, лексиконы и библиотеки - это разные категории.
Gudleifr> Минус - теряется преимущество FORTH-подхода, программа становится практически неотличимой от написанной на Си.
Что за преимущество FORTH-подхода?
Gudleifr> 2. Прятать внутрь интерпретатора?
Форт-интерпретатор должен только передавать управление на слова разделенные
пробелом поданные ему на вход. В это суть Форта.
Gudleifr> Например, так обеспечивается работа с FORTH-консолью в графических ОС и реализуется классическая многопользовательность путем переключения пользовательских областей.
Взаимодействие с консолью осуществляется по средствам процедур ввода/вывода.
Какое отношение к этому имеет интерпретатор?
Gudleifr> Плюс - FORTH-программы просты и стандартны.
Если форт-интерпретатор нестандартный то и сам Форт стандартный.
Gudleifr> 4. Использовать более одного интерпретатора?
Gudleifr> Например, у меня в FOBOS есть две форт-системы, объединенные общим словарем: одна заполняет словарь необходимыми для примера определениями, другая обрабатывает Win-сообщения примера.
У тебя Win-сообщения обрабатывает форт-интерпретатор?
Тогда, Win должен генерить форт исходники.
mak44> Заранее определяться с направлениями нужно только если эти направления друг-другу противоречат.
Тут хитрее: противоречат не столько сами направления, очевидно, не существующие в чистом виде, сколько наше их восприятие. Т.к. теории этого вопроса пока нет, то провести строго ортогональные оси отсчета пока невозможно.
mak44> По моему...
Дело в том, что Ваше понимание FORTH базируется на "словах, разделенных пробелом".
Но это - лишь условность. Да, когда-то такой способ ввода был наиболее универсальным и попал в FORTH по причине использования Основного Принципа ("Пусть будет просто!").
Но для самой FORTH-системы глубоко пофигу, как формируются символы (в смысле машины Тьюринга) подаваемые ей на вход.
К FORTH-подходу это частное техническое решение отношения не имеет (например, сам Мур сейчас предлагает слова раскрашивать).
mak44> Что за преимущество FORTH-подхода?
Устранение избыточности путем возложения ответственности на все написанное только на автора. Язык программирования задачи выбирается не универсальным, а создается по необходимости.
Тут хитрее: противоречат не столько сами направления, очевидно, не существующие в чистом виде, сколько наше их восприятие. Т.к. теории этого вопроса пока нет, то провести строго ортогональные оси отсчета пока невозможно.
mak44> По моему...
Дело в том, что Ваше понимание FORTH базируется на "словах, разделенных пробелом".
Но это - лишь условность. Да, когда-то такой способ ввода был наиболее универсальным и попал в FORTH по причине использования Основного Принципа ("Пусть будет просто!").
Но для самой FORTH-системы глубоко пофигу, как формируются символы (в смысле машины Тьюринга) подаваемые ей на вход.
К FORTH-подходу это частное техническое решение отношения не имеет (например, сам Мур сейчас предлагает слова раскрашивать).
mak44> Что за преимущество FORTH-подхода?
Устранение избыточности путем возложения ответственности на все написанное только на автора. Язык программирования задачи выбирается не универсальным, а создается по необходимости.
Это сообщение редактировалось 10.04.2014 в 21:36
mak44
новичок
Gudleifr> Ваше понимание FORTH базируется на "словах, разделенных пробелом".
мое понимание FORTH базируется на его устройстве. Прежде всего словарь.
Главное, прямой доступ ко всем его компонентам.
Gudleifr> Но это - лишь условность. Да, когда-то такой способ ввода был наиболее универсальным и попал в FORTH по причине использования Основного Принципа ("Пусть будет просто!").
В основе должна быть простота. Я хотел бы видеть в рамках форт-системы многие
интерпретаторы(компиляторы), Но вызываться они должны примитивным форт-интерпретатором,
который, при этом, выступает в качестве языка управления заданием.
mak44>> Что за преимущество FORTH-подхода?
Gudleifr> Устранение избыточности путем возложения ответственности на все написанное только на автора.
Использование высокоуровневых процедур в Форте имеет рекомендательный характер.
Низкий уровню также доступен.
мое понимание FORTH базируется на его устройстве. Прежде всего словарь.
Главное, прямой доступ ко всем его компонентам.
Gudleifr> Но это - лишь условность. Да, когда-то такой способ ввода был наиболее универсальным и попал в FORTH по причине использования Основного Принципа ("Пусть будет просто!").
В основе должна быть простота. Я хотел бы видеть в рамках форт-системы многие
интерпретаторы(компиляторы), Но вызываться они должны примитивным форт-интерпретатором,
который, при этом, выступает в качестве языка управления заданием.
mak44>> Что за преимущество FORTH-подхода?
Gudleifr> Устранение избыточности путем возложения ответственности на все написанное только на автора.
Использование высокоуровневых процедур в Форте имеет рекомендательный характер.
Низкий уровню также доступен.
mak44> мое понимание FORTH базируется на его устройстве.
Тогда имеет смыл вернуться к обсуждаемому вопросу.
Тогда имеет смыл вернуться к обсуждаемому вопросу.
Чтобы было понятнее, приведу пример:
Посмотрим на PatternForth от Родригеса: методом добавления новых лексиконов (1) он расширил FORTH ассоциативными хранилищами строк, строковыми операциями и операцией сравнения строки с шаблоном. Кому лень читать первоисточник, можете посмотреть у меня пересказ.
При всех достоинствах проекта можно отметить следующие очевидные недостатки:
Попробуем посмотреть, нельзя ли применить другие методы:
(2) - упрятывание в интерпретатор. Конечно! Ведь предложенный механизм работы со строками практически делает работу FIND. Не проще ли переписать свой FORTH так, чтобы словари могли занимать более 64Kb (размещаться по-блочно) и хранить более длинные имена (с пробелами)? Можно и хеширование добавить... И все. Фортер даже не будет знать, что хранение и поиск строк что-то "весят".
(3) - нестандартный интерпретатор. Думаю, можно доказать, что подогнать язык шаблонов под стандарты FORTH-языка невозможно (разве что, применить стек приоритетов, как классики делали с инфиксной арифметикой). Но зачем? Интерпретатор для шаблонов давно описан и обсчитан (конечные автоматы). Так добавим к нашей FORTH-системе еще пару процедур - чтения-применения регулярных выражений. Создадим дополнительное хранилище для построенных конечных автоматов...
(4) - несколько интерпретаторов. Возвращаемся к постановке задачи. Не будет ли наш FORTH слишком тяжеловесным, получив "на борт" все эти строковые механизмы? Ведь он должен еще и что-то делать? Так может объединим две FORTH-системы: одна маленькая (на 64Kb) - для работы - и большой строковый процессор. Точнее, даже, наоборот. Большой FORTH-управлятор многими видами памяти (в т.ч. строковыми) будет содержать и рабочую FORTH-систему (которой выделит немного места и пару потоков ввода-вывода). Но, опять же, т.к. теории этого дела нет, фантазировать можно сколько угодно...
Посмотрим на PatternForth от Родригеса: методом добавления новых лексиконов (1) он расширил FORTH ассоциативными хранилищами строк, строковыми операциями и операцией сравнения строки с шаблоном. Кому лень читать первоисточник, можете посмотреть у меня пересказ.
При всех достоинствах проекта можно отметить следующие очевидные недостатки:
- перевод разговора на обсуждение лексиконов замаскировал тот факт, что задача управления памятью оказалась, по-сути, нерешенной (мол, сами доработайте свой FORTH для работы за пределами 64Kb).
- C-подобный набор строковых операций - вещь совершенно не нужная в реальном программировании.
- предложенный язык шаблонов слишком тяжеловесен.
Попробуем посмотреть, нельзя ли применить другие методы:
(2) - упрятывание в интерпретатор. Конечно! Ведь предложенный механизм работы со строками практически делает работу FIND. Не проще ли переписать свой FORTH так, чтобы словари могли занимать более 64Kb (размещаться по-блочно) и хранить более длинные имена (с пробелами)? Можно и хеширование добавить... И все. Фортер даже не будет знать, что хранение и поиск строк что-то "весят".
(3) - нестандартный интерпретатор. Думаю, можно доказать, что подогнать язык шаблонов под стандарты FORTH-языка невозможно (разве что, применить стек приоритетов, как классики делали с инфиксной арифметикой). Но зачем? Интерпретатор для шаблонов давно описан и обсчитан (конечные автоматы). Так добавим к нашей FORTH-системе еще пару процедур - чтения-применения регулярных выражений. Создадим дополнительное хранилище для построенных конечных автоматов...
(4) - несколько интерпретаторов. Возвращаемся к постановке задачи. Не будет ли наш FORTH слишком тяжеловесным, получив "на борт" все эти строковые механизмы? Ведь он должен еще и что-то делать? Так может объединим две FORTH-системы: одна маленькая (на 64Kb) - для работы - и большой строковый процессор. Точнее, даже, наоборот. Большой FORTH-управлятор многими видами памяти (в т.ч. строковыми) будет содержать и рабочую FORTH-систему (которой выделит немного места и пару потоков ввода-вывода). Но, опять же, т.к. теории этого дела нет, фантазировать можно сколько угодно...
Это сообщение редактировалось 11.09.2021 в 14:52
20 лет назад мне доводилось работать с Фортом на уровне драйверов. Это был DOS-Форт (Forthius), работающий с кучей железа спутниковой связи. Голову не заморачивали. Если устройство было простой с одной-двумя командами управления, то соответствующие слова лежали в главном словаре. Если был богатый набор управляющий слов, то под них, чтобы не мусорить, заводился отдельный словарь. Вообще, мы тогда работу с этими устройствами как драйвера даже не воспринимали. Такие же Форт-слова, как и всё остальное.
Получается примерно так:
1. FORTH-машина состоит из нескольких частей
2. Взаимопроникновение частей, как показывает опыт FORTH-строения и вопреки "общепринятому" мнению, минимально
Тогда приведенные в начале темы варианты:
1. "лексиконостроение" - увеличение степени взаимопроникновения частей
2. "инкапсуляция" - замена некоторых частей на другие, внешне такие же
3. "спец.машина" - изменение общего количества частей
4. "втор.машина" - использование нескольких наборов частей (при этом неизбежно возникнет взаимопроникновение, что объясняет изначальное сродство решений (1) и (4)).
1. FORTH-машина состоит из нескольких частей
2. Взаимопроникновение частей, как показывает опыт FORTH-строения и вопреки "общепринятому" мнению, минимально
Тогда приведенные в начале темы варианты:
1. "лексиконостроение" - увеличение степени взаимопроникновения частей
2. "инкапсуляция" - замена некоторых частей на другие, внешне такие же
3. "спец.машина" - изменение общего количества частей
4. "втор.машина" - использование нескольких наборов частей (при этом неизбежно возникнет взаимопроникновение, что объясняет изначальное сродство решений (1) и (4)).
Gudleifr> Итак, на входе - обычный FORTH, не имеющий на борту ничего, кроме того, что необходимо для его работы (саморазвития). Нам надо расширить его...
Эк я размахнулся... На кошачьем форуме, наоборот, ВСЕРЬЕЗ обсуждают, допустимо ли использовать в FORTH-программах слова, которые имеют доступ к внутренностям FORTH. Например, слова работы со стеком возвратов...
О каком [само]развитии можно после этого говорить?
Эк я размахнулся... На кошачьем форуме, наоборот, ВСЕРЬЕЗ обсуждают, допустимо ли использовать в FORTH-программах слова, которые имеют доступ к внутренностям FORTH. Например, слова работы со стеком возвратов...
О каком [само]развитии можно после этого говорить?
Copyright © Balancer 1997..2021
Создано 10.04.2014
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
Создано 10.04.2014
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
