Автор |
Сообщение |
|
|
Заголовок сообщения: |
Re: Модули в Форте |
|
|
Взаимозаменяемость, при совместимости интерфейса.
Если в языке есть расширяемость типов («наследование» в ООП), должна быть предусмотрена возможность расширять типы, импортированные из модуля.
Возможно, ещё раздельная компиляция. Надо почитать талмуды, напишу точно.
Взаимозаменяемость, при совместимости интерфейса.
Если в языке есть расширяемость типов («наследование» в ООП), должна быть предусмотрена возможность расширять типы, импортированные из модуля.
Возможно, ещё раздельная компиляция. Надо почитать талмуды, напишу точно.
|
|
|
|
Добавлено: Пт окт 26, 2018 20:54 |
|
|
|
|
|
Заголовок сообщения: |
Re: Модули в Форте |
|
|
Так а какую роль должны выполнять модули?
Сокрытие реализации. понятно Что ещё?
Так а какую роль должны выполнять модули?
Сокрытие реализации. понятно Что ещё?
|
|
|
|
Добавлено: Пт окт 26, 2018 12:23 |
|
|
|
|
|
Заголовок сообщения: |
Re: Модули в Форте |
|
|
В принципе, это выход. Внешний словарь может содержать лишь интерфейс, а словарные статьи реализации лишены заголовков.
Вопрос в том, как это красиво уложить в синтаксис. Как эти модули потом загружать, как они вообще будут компилироваться и взаимодействовать.
Вроде, в некоторых системах была даже предусмотрена горячая замена модулей. Когда один из модулей заменялся на совместимый (например, свою новую версию), а зависимые от него модули продолжали работу. Или приостанавливались на время, могу путать.
В принципе, это выход. Внешний словарь может содержать лишь интерфейс, а словарные статьи реализации лишены заголовков.
Вопрос в том, как это красиво уложить в синтаксис. Как эти модули потом загружать, как они вообще будут компилироваться и взаимодействовать.
Вроде, в некоторых системах была даже предусмотрена горячая замена модулей. Когда один из модулей заменялся на совместимый (например, свою новую версию), а зависимые от него модули продолжали работу. Или приостанавливались на время, могу путать.
|
|
|
|
Добавлено: Пт окт 26, 2018 01:55 |
|
|
|
|
|
Заголовок сообщения: |
Re: Модули в Форте |
|
|
Всё ещё не понимаю в полной мере. Что же требуется от модулей в форте? Можно же взять все нужные для разработки слова и запихнуть их в словарь. А во внешнем словаре будут только необходимые (тот самый интерфейс)
Вот вам и сокрытие данных и полиформизм.
Этот подход применяется в словарных фортах часто. В Нове есть примеры, в СПФ есть примеры.
Всё ещё не понимаю в полной мере. Что же требуется от модулей [b]в форте?[/b] Можно же взять все нужные для разработки слова и запихнуть их в словарь. А во внешнем словаре будут только необходимые (тот самый интерфейс)
Вот вам и сокрытие данных и полиформизм.
Этот подход применяется в словарных фортах часто. В Нове есть примеры, в СПФ есть примеры.
|
|
|
|
Добавлено: Вт окт 23, 2018 17:56 |
|
|
|
|
|
Заголовок сообщения: |
Re: Модули в Форте |
|
|
Victor__v Позиционно независимый код позволит раздельную компиляцию модулей. Откуда можно переходить к динамической загрузке, что весьма экономно. В идеале единственная копия модуля в памяти может обслуживать сразу несколько программ — исполняющихся параллельно или последовательно.
Но модули могут и компилироваться вместе, как INCLUDE
Интересен лаконичный синтаксис. В Форте приживается то, что связано с эффективной реализацией. Часто удаётся найти идеал.
Например, сейчас кодирую ACCEPT на языке «Электроники МК-161», оформив этот язык в виде форт-ассемблера. И фортовские if then, begin until удивительно точно ложатся на код — избавляя его от меток и не приводя к жертвам ни по размеру кода, ни по быстродействию.
Интересно найти такое же решение для модулей. Возможно, кто-то уже его нашёл и использует.
[b]Victor__v[/b] Позиционно независимый код позволит раздельную компиляцию модулей. Откуда можно переходить к динамической загрузке, что весьма экономно. В идеале единственная копия модуля в памяти может обслуживать сразу несколько программ — исполняющихся параллельно или последовательно.
Но модули могут и компилироваться вместе, как INCLUDE
Интересен лаконичный синтаксис. В Форте приживается то, что связано с эффективной реализацией. Часто удаётся найти идеал.
Например, сейчас кодирую ACCEPT на языке «Электроники МК-161», оформив этот язык в виде форт-ассемблера. И фортовские if then, begin until удивительно точно ложатся на код — избавляя его от меток и не приводя к жертвам ни по размеру кода, ни по быстродействию.
Интересно найти такое же решение для модулей. Возможно, кто-то уже его нашёл и использует.
|
|
|
|
Добавлено: Вт окт 23, 2018 13:51 |
|
|
|
|
|
Заголовок сообщения: |
Re: Модули в Форте |
|
|
Целевая компиляция, afaik, больше относится к кросс-компиляции. Этот механизм можно использовать для компиляции модулей?
Классические модули экспортируют три вещи — типы, переменные и процедуры. Можно продумать интерфейс, как список экспортируемых слов. Создавать их могут, например, слова со звёздочкой (как в Обероне). Для экспорта процедур: :* X … ;
Для экспорта переменных: VARIABLE* V CREATE* TBL
В обычном Форте роль типов, видимо, выполняют порождающие слова, например CREATE … DOES>
Но если мы хотим экспортировать переменную своего типа — придётся дублировать порождающее слово с CREATE* ? И как экспортировать сам модуль, включая его интерфейс?
Также нужно продумать синтаксис для импорта модулей и как реализовать изменения в поиске слов, чтобы компилятор искал и среди экспорта.
Целевая компиляция, 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:
Можно сделать а-ля форт-словарь с позиционно-независимым кодом. Интерфейс это имена. А код это код Всё просто :) Нужно только, чтобы форт-система умела подключать позиционно-независимый код. Я недавно наварганил создание оверлеев. Можно сказать почти модули.
[code] Что хотелось бы? Возможность обращения к импортируемым словам через точку. Например, если фортовские модули A и B экспортируют слово X — хотелось бы обращаться к ним из модуля C , как к A.X и B.X [/code] Это уже мелочи. В СПФ же подобное для доступа к словарям. Там, кстати, есть слово MODULE: 8)
|
|
|
|
Добавлено: Сб окт 20, 2018 20:42 |
|
|
|
|
|
Заголовок сообщения: |
Модули в Форте |
|
|
Интересуют как уже существующие реализации модульности в Форте, так и возможные подходы.
Чтобы сузить тему, немного о том, что здесь назовём модулями. Модули это ключевая концепция компьютерных наук, предложенная проф. Виртом в языке «Модула-2». Модули предназначены для независимой разработки программ, взаимодействующих друг с другом, возможно, разными коллективами программистов. Модульность развивает низкоуровневые идеи библиотек и юнитов. Модульность повлияла на индустрию через «инкапсуляцию» в ООП.
/* По теории проф. Вирта модное сокрытие полей записей (классов) в ООП это архитектурное уродство. Отцы ООП мало времени провели за партами и беспродуманно бросились кодировать, что им в голову взбрело. Услышали звон, да не поняли, где он.
Модульность, куда действительно входит сокрытие деталей реализации, ортогональна системе типов и при проектировании языка смешивать эти два независимых понятия (как сделано в C++ и последующих языках) безграмотно и только мешает программистам. */
Модуль состоит из двух частей — интерфейса и реализации. Интерфейс содержит полное формальное описание типов данных, переменных и функций, доступных извне модуля — теми, кто импортирует этот модуль.
Реализация содержит код модуля. Модули с одинаковым интерфейсом должны быть взаимозаменяемы, даже если имеют разные реализации. Например, можно разработать универсальный интерфейс сортировки массива и через него подключать к своим модулям сперва пузырьковую, а потом быструю реализации.
Идеологически проф. Вирт противопоставляет концепцию модульности «открытым исходникам». От сторонников «открытых исходников» можно часто услышать: «мой код открыт, загляни туда и всё поймёшь». По идеологии модульности должно быть достаточно «заглянуть» в исходный текст интерфейса — от реализации модуля зависимости быть не должно.
Интересно, что в авторском Обероне-2 модульность не столь строгая, как в Модуле-2. Разработчик модуля помечает экспортируемые функции в заголовке их определений, а компилятор сам строит файл интерфейса, наряду с объектным кодом модуля.
Что хотелось бы? Возможность обращения к импортируемым словам через точку. Например, если фортовские модули A и B экспортируют слово X — хотелось бы обращаться к ним из модуля C , как к A.X и B.X
Но это в идеале. Интересно, какие подходы уже испробованы и работают, оказались полезны. И мысли на перспективу.
Интересуют как уже существующие реализации модульности в Форте, так и возможные подходы.
Чтобы сузить тему, немного о том, что здесь назовём модулями. Модули это ключевая концепция компьютерных наук, предложенная проф. Виртом в языке «Модула-2». Модули предназначены для независимой разработки программ, взаимодействующих друг с другом, возможно, разными коллективами программистов. Модульность развивает низкоуровневые идеи библиотек и юнитов. Модульность повлияла на индустрию через «инкапсуляцию» в ООП.
/* По теории проф. Вирта модное сокрытие полей записей (классов) в ООП это архитектурное уродство. Отцы ООП мало времени провели за партами и беспродуманно бросились кодировать, что им в голову взбрело. Услышали звон, да не поняли, где он.
Модульность, куда действительно входит сокрытие деталей реализации, ортогональна системе типов и при проектировании языка смешивать эти два независимых понятия (как сделано в C++ и последующих языках) безграмотно и только мешает программистам. */
Модуль состоит из двух частей — интерфейса и реализации. Интерфейс содержит полное формальное описание типов данных, переменных и функций, доступных извне модуля — теми, кто импортирует этот модуль.
Реализация содержит код модуля. Модули с одинаковым интерфейсом должны быть взаимозаменяемы, даже если имеют разные реализации. Например, можно разработать универсальный интерфейс сортировки массива и через него подключать к своим модулям сперва пузырьковую, а потом быструю реализации.
Идеологически проф. Вирт противопоставляет концепцию модульности «открытым исходникам». От сторонников «открытых исходников» можно часто услышать: «мой код открыт, загляни туда и всё поймёшь». По идеологии модульности должно быть достаточно «заглянуть» в исходный текст интерфейса — от реализации модуля зависимости быть не должно.
Интересно, что в авторском Обероне-2 модульность не столь строгая, как в Модуле-2. Разработчик модуля помечает экспортируемые функции в заголовке их определений, а компилятор сам строит файл интерфейса, наряду с объектным кодом модуля.
Что хотелось бы? Возможность обращения к импортируемым словам через точку. Например, если фортовские модули A и B экспортируют слово X — хотелось бы обращаться к ним из модуля C , как к A.X и B.X
Но это в идеале. Интересно, какие подходы уже испробованы и работают, оказались полезны. И мысли на перспективу.
|
|
|
|
Добавлено: Сб окт 20, 2018 19:48 |
|
|
|
|