Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Вт мар 19, 2024 13:01

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Ответить
Имя пользователя:
Заголовок:
Текст сообщения:
Введите текст вашего сообщения. Длина сообщения в символах не более: 60000

Размер шрифта:
Цвет шрифта
Настройки:
BBCode ВКЛЮЧЕН
[img] ВЫКЛЮЧЕН
[flash] ВЫКЛЮЧЕН
[url] ВКЛЮЧЕН
Смайлики ВЫКЛЮЧЕНЫ
Отключить в этом сообщении BBCode
Не преобразовывать адреса URL в ссылки
Вопрос
Теперь гостю придется вводить здесь пароль. Не от своей учетной записи, а ПАРОЛЬ ДЛЯ ГОСТЯ, получить который можно после регистрации на форуме через ЛС.:
Этот вопрос предназначен для выявления и предотвращения автоматических регистраций.
   

Обзор темы - Модули в Форте
Автор Сообщение
  Заголовок сообщения:  Re: Модули в Форте  Ответить с цитатой
Взаимозаменяемость, при совместимости интерфейса.

Если в языке есть расширяемость типов («наследование» в ООП), должна быть предусмотрена возможность расширять типы, импортированные из модуля.

Возможно, ещё раздельная компиляция. Надо почитать талмуды, напишу точно.
Сообщение Добавлено: Пт окт 26, 2018 20:54
  Заголовок сообщения:  Re: Модули в Форте  Ответить с цитатой
Так а какую роль должны выполнять модули?

Сокрытие реализации. понятно
Что ещё?
Сообщение Добавлено: Пт окт 26, 2018 12:23
  Заголовок сообщения:  Re: Модули в Форте  Ответить с цитатой
В принципе, это выход. Внешний словарь может содержать лишь интерфейс, а словарные статьи реализации лишены заголовков.

Вопрос в том, как это красиво уложить в синтаксис. Как эти модули потом загружать, как они вообще будут компилироваться и взаимодействовать.

Вроде, в некоторых системах была даже предусмотрена горячая замена модулей. Когда один из модулей заменялся на совместимый (например, свою новую версию), а зависимые от него модули продолжали работу. Или приостанавливались на время, могу путать.
Сообщение Добавлено: Пт окт 26, 2018 01:55
  Заголовок сообщения:  Re: Модули в Форте  Ответить с цитатой
Всё ещё не понимаю в полной мере.
Что же требуется от модулей в форте?
Можно же взять все нужные для разработки слова и запихнуть их в словарь. А во внешнем словаре будут только необходимые (тот самый интерфейс)

Вот вам и сокрытие данных и полиформизм.

Этот подход применяется в словарных фортах часто.
В Нове есть примеры, в СПФ есть примеры.
Сообщение Добавлено: Вт окт 23, 2018 17:56
  Заголовок сообщения:  Re: Модули в Форте  Ответить с цитатой
Victor__v
Позиционно независимый код позволит раздельную компиляцию модулей. Откуда можно переходить к динамической загрузке, что весьма экономно. В идеале единственная копия модуля в памяти может обслуживать сразу несколько программ — исполняющихся параллельно или последовательно.

Но модули могут и компилироваться вместе, как INCLUDE

Интересен лаконичный синтаксис. В Форте приживается то, что связано с эффективной реализацией. Часто удаётся найти идеал.

Например, сейчас кодирую ACCEPT на языке «Электроники МК-161», оформив этот язык в виде форт-ассемблера. И фортовские if then, begin until удивительно точно ложатся на код — избавляя его от меток и не приводя к жертвам ни по размеру кода, ни по быстродействию.

Интересно найти такое же решение для модулей. Возможно, кто-то уже его нашёл и использует.
Сообщение Добавлено: Вт окт 23, 2018 13:51
  Заголовок сообщения:  Re: Модули в Форте  Ответить с цитатой
Целевая компиляция, afaik, больше относится к кросс-компиляции. Этот механизм можно использовать для компиляции модулей?

Классические модули экспортируют три вещи — типы, переменные и процедуры. Можно продумать интерфейс, как список экспортируемых слов. Создавать их могут, например, слова со звёздочкой (как в Обероне). Для экспорта процедур:
:* X … ;

Для экспорта переменных:
VARIABLE* V
CREATE* TBL

В обычном Форте роль типов, видимо, выполняют порождающие слова, например CREATE … DOES>

Но если мы хотим экспортировать переменную своего типа — придётся дублировать порождающее слово с CREATE* ? И как экспортировать сам модуль, включая его интерфейс?

Также нужно продумать синтаксис для импорта модулей и как реализовать изменения в поиске слов, чтобы компилятор искал и среди экспорта.
Сообщение Добавлено: Сб окт 20, 2018 22:08
  Заголовок сообщения:  Re: Модули в Форте  Ответить с цитатой
Возможно стоит уточнить понятие "целевая компиляция" в форте.
Везде поминается, нигде не конкретизируется.
Теоретически, можно натянуть на что угодно, в том числе и на модули.
Я за, обеими руками(и ногами).
Сообщение Добавлено: Сб окт 20, 2018 21:08
  Заголовок сообщения:  Re: Модули в Форте  Ответить с цитатой
Можно сделать а-ля форт-словарь с позиционно-независимым кодом.
Интерфейс это имена. А код это код Всё просто :)
Нужно только, чтобы форт-система умела подключать позиционно-независимый код.
Я недавно наварганил создание оверлеев. Можно сказать почти модули.

Код:
Что хотелось бы? Возможность обращения к импортируемым словам через точку. Например, если фортовские модули A и B экспортируют слово X — хотелось бы обращаться к ним из модуля C , как к A.X и B.X

Это уже мелочи.
В СПФ же подобное для доступа к словарям. Там, кстати, есть слово MODULE: 8)
Сообщение Добавлено: Сб окт 20, 2018 20:42
  Заголовок сообщения:  Модули в Форте  Ответить с цитатой
Интересуют как уже существующие реализации модульности в Форте, так и возможные подходы.

Чтобы сузить тему, немного о том, что здесь назовём модулями. Модули это ключевая концепция компьютерных наук, предложенная проф. Виртом в языке «Модула-2». Модули предназначены для независимой разработки программ, взаимодействующих друг с другом, возможно, разными коллективами программистов. Модульность развивает низкоуровневые идеи библиотек и юнитов. Модульность повлияла на индустрию через «инкапсуляцию» в ООП.

/* По теории проф. Вирта модное сокрытие полей записей (классов) в ООП это архитектурное уродство. Отцы ООП мало времени провели за партами и беспродуманно бросились кодировать, что им в голову взбрело. Услышали звон, да не поняли, где он.

Модульность, куда действительно входит сокрытие деталей реализации, ортогональна системе типов и при проектировании языка смешивать эти два независимых понятия (как сделано в C++ и последующих языках) безграмотно и только мешает программистам.
*/

Модуль состоит из двух частей — интерфейса и реализации. Интерфейс содержит полное формальное описание типов данных, переменных и функций, доступных извне модуля — теми, кто импортирует этот модуль.

Реализация содержит код модуля. Модули с одинаковым интерфейсом должны быть взаимозаменяемы, даже если имеют разные реализации. Например, можно разработать универсальный интерфейс сортировки массива и через него подключать к своим модулям сперва пузырьковую, а потом быструю реализации.

Идеологически проф. Вирт противопоставляет концепцию модульности «открытым исходникам». От сторонников «открытых исходников» можно часто услышать: «мой код открыт, загляни туда и всё поймёшь». По идеологии модульности должно быть достаточно «заглянуть» в исходный текст интерфейса — от реализации модуля зависимости быть не должно.

Интересно, что в авторском Обероне-2 модульность не столь строгая, как в Модуле-2. Разработчик модуля помечает экспортируемые функции в заголовке их определений, а компилятор сам строит файл интерфейса, наряду с объектным кодом модуля.

Что хотелось бы? Возможность обращения к импортируемым словам через точку. Например, если фортовские модули A и B экспортируют слово X — хотелось бы обращаться к ним из модуля C , как к A.X и B.X

Но это в идеале. Интересно, какие подходы уже испробованы и работают, оказались полезны. И мысли на перспективу.
Сообщение Добавлено: Сб окт 20, 2018 19:48

Часовой пояс: UTC + 3 часа [ Летнее время ]


cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB