OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 20:34

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 6 ] 
Автор Сообщение
СообщениеДобавлено: Четверг, 27 Февраль, 2020 22:26 

Зарегистрирован: Среда, 31 Октябрь, 2007 18:58
Сообщения: 252
Откуда: Austria, Bruck
В обсуждении темы Распол-е модулей System. Все еще актуально брать из корня? для меня всплыли немного другие темы:
1) Понятие "подсистема" несколько размыто и в сущности ничего из себя не представляет в языке КП.
В том виде как оно есть это скорее попытка сделать "костыль" при переходе от плоской структуры ФС ОберонОС в иерархическую ФС Windows и заодно удовлетворить потребности каркаса ББ. Тогда о чем рассуждения?
2) Если говорим о понятии "подсистема(-ы)" то что тогда "система"?
3) Стоит ли вообще привязывать механизм хранения модулей и ресурсов (организация файлов в ФС) к этим понятиям?

Может быть кто-нибудь объяснит?

Я же вижу так:
  • "Система" - это пара описателей архитектуры компьютера и его ОС которой соответствует свой набор (множество) модулей и подсистем
  • "Подсистема" - это набор модулей и других ресурсов связанных одной задачей (для простоты реализации можно также воспользоваться определением Trurl). Причем, (пошла крамола) язык надо дополнить так чтобы можно было ограничить список экспортируемых символов для "внешней среды" (т.е. модулей не входящих в данную подсистему) **

** Это поможет решить проблему изоляции "подcистемы" Host: все модули внутри "подсистемы" могут импортировать друг друга, но вот модули НЕ входящие в подсистему НЕ СМОГУТ использовать экспортированные символы.
Например:
Код:
MODULE HostFiles;
...
PROCEDURE GetModDate!* (f: Files.File; VAR year, month, day, hour, minute, second: INTEGER);
(* !* - говорит о том что данный символ может использоваться только для модулей HostXXXX *)
END HostFiles.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Февраль, 2020 01:14 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Для этой задачи - ограничить импорт - вовсе не обязательно менять язык. Достаточно инструментального средства, которое будет проверять соответствие (откомпилированного) модуля М вашим правилам. Если очень надо - можно эту проверку сделать в компоновщике-загрузчике.
Но, кмк, вводить отдельный scope для подсистем - не вижу практического смысла и выгоды. Этак можно до friend договориться и раздуть компилятор, замучив компиляторщиков проверками.

Цитата:
1) Понятие "подсистема" несколько размыто и в сущности ничего из себя не представляет в языке КП.

Так и есть - в КП его нет

Цитата:
В том виде как оно есть это скорее попытка сделать "костыль" при переходе от плоской структуры ФС ОберонОС

Почему костыль? Оберон и КП вообще ничего не говорят о файлах. Файлы появляются как соглашение системы-среды ББ.

Цитата:
3) Стоит ли вообще привязывать механизм хранения модулей и ресурсов (организация файлов в ФС) к этим понятиям?


Как я раньше писал, совсем их невозможно отвязать; однако привязка должна быть в одну сторону: определение модуля не должно ссылаться ни на какие файлы/каталоги. Модуль - это текст, который удовлетворяет грамматике КП и его семантическим правилам. Он может быть написан на салфетке или карандашом прямо на столе. Однако в системе должны быть приняты соглашения о том, какие файлы соответствуют модулю (if any), и где они расположены. Без таких соглашений инструментальные средства оч сложно сделать.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Февраль, 2020 11:53 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 987
Откуда: Казань
Удивительно, но я сам недавно думал над этими проблемами (видимо многие идеи витают в воздухе и считываются из ноосферы :) ).
По пунктам распишу о чем думал:
1) Одной из ранних методологий программирования, которая была призвана решить "кризис программирования" была методология структурного программирования. Структурное программирование можно охарактеризовать тремя вещами: разработка сверху вниз, использование только структурных переходов и доказательство корректности системы на каждом шаге декомпозиции (формальное или неформальное).
В те годы во многих книгах по программированию обсуждается проблема того, как лучше разрабатывать модули системы сверху вниз или же снизу вверх. Недостатками метода сверху вниз является то, что каждый модуль декомпозиции является частью решения именно этой задачи и может не подойти для решение почти такой же, но немного другой задачи. Также проблемой является изменение спецификаций, если какие-то требования меняются, то это может повлечь изменение многих дочерних модулей.
Метод разработки снизу вверх использовался Дейкстрой при разработке операционной системы THE. У метода снизу вверх есть преимущество, что низ лежащие компоненты могут быть довольно универсальными и использоваться в различных проектах. Но при интеграции различных компонент в единое целое могут возникать проблемы с тем, что что-то плохо стыкуется и так далее.
Также в книгах, где затрагивается тема тестирования, обсуждается то, как лучше тестировать: сверху вниз или снизу вверх. Если тестировать сверху вниз, то низ лежащие модули надо заменить на заглушки, но преимущество в том, что уже с самого начала тестируется целая система пусть и с некоторыми заглушками. При тестировании снизу вверх преимущество в том, что можно тестировать сразу полноценный низ лежащий слой (например, вывод в лог или на экран или в консоль и т.д.) и не нужно писать заглушек для тестирования системы.
Затем пришла эра объекто-ориентированного программирования и многие эти темы стали малоактуальными. Вопрос про то, как лучше разрабатывать сверху вниз или снизу вверх по сути отпал, так как объектно-ориентированные системы могут представлять собой сеть или граф взаимозависимых объектов (например, шаблон MVC). Начали обсуждать вопросы шаблонов проектирования: как лучше организовать эти объекты. А вопрос доказательства программы стали умалчивать, так как было не понятно, как вообще можно что-либо доказывать с этими наследованиями, полиморфизмами и так далее. Барбара Лисков получила Тьюринговскую премию за то, что сформулировала принцип подстановки. Простыми словами, который можно сформулировать так, что при полиморфизме новый метод должен обладать не более сильным предусловием, чем исходный метод (иначе данный метод может упасть, если ему передать значение, которое не входит в его предусловие, но входило в предусловие его предка) и не более слабым постусловие (иначе может упасть вызывающая программа, так как может не принять результаты, которые возвращает данный метод). Но на практике мало кто применяет этот принцип и, соответственно, практически не используется для доказательства, так как при полиморфизме многие не следуют этому принципу, а по сути используют полиморфизм, как некий goto, который позволяет перейти в другое место и сделать что-то совершенно отличное от того, что делал родительский метод.
Горбунов-Посадов в книге "Расширяемое программирование" говорит о том, что метод сверху вниз является по сути анализом, а снизу вверх - синтезом. Анализ и синтез - это основные инструменты логического мышления человека и оба важны, поэтому надо анализировать как систему декомпозировать, а затем уже синтезировать. Этим он как бы примиряет оба метода и снизу вверх и сверху вниз.
2) Горбунов-Посадов в книге "Расширяемое программирование" затрагивает еще более высокоуровневые вопросы, например, как выделять вариант. Допустим, у нас есть несколько вариантов каких-то алгоритмов, например, у нас есть такой сборщик мусора и другой сборщик мусора и мы хотим иметь возможность довольно просто переключаться между ними. Также он говорит про разные варианты таких переключений, один из вариантов - это цепочечный подход, когда от порядка перечисления чего-либо, мы имеем различные варианты (например в BlackBox, при создании exe мы можем указать порядок включения модулей и соответственно порядок инициализации модулей, от этого порядка может зависеть то, какие функции будут инсталлированы и будут выполняться). Сам он говорит, что цепочечный подход не очень хорош, так как есть вероятность совершить ошибку и при небольшом изменении нужно переписать всю цепочку. Он также говорит, про задачу сокращения записи, что надо стремиться к тому, чтобы общие подвыражения не переписывать, а описывать только то, что поменялось.
3) Лично я считаю, что расположение модулей в системе должно быть не одноуровневым и не двухуровневым, а многоуровневым, как дерево (аналогия с методами сверху вниз и снизу вверх). Можно привести аналогию с языком Oberon-07 (и другими Oberon-нами), где разрешены вложенные подпрограммы. В Oberon-07 есть правило, что вложенная подпрограмма может обращаться к своим локальным переменным или же к переменным глобального уровня. Думаю, что что-то типа этого правила можно ввести и для модулей, что модули внутри какой-то папки (подсистемы) могут обращаться к модулям глобального уровня, своего уровня и своего дочернего уровня (но не к подмодулям дочернего уровня). Также нужно продумать то, как легко можно переключаться между вариантами реализации. Думаю, что можно создать один модуль интерфейса, который в IMPORT подключает один из вариантов модуля реализации. Таким образом, можно будет легко менять вариант реализации. Списки модулей, которые надо включить для сборки проекта должны включаться внутрь каждой подсистемы, чтобы на верхнем уровне указывать только включаемые подсистемы, а их списки подмодулей подключатся автоматически.
Пока это еще не завершенная идея, возможно, что-то здесь не совсем хорошо, надо еще думать над этим.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Февраль, 2020 16:56 

Зарегистрирован: Среда, 31 Октябрь, 2007 18:58
Сообщения: 252
Откуда: Austria, Bruck
adimetrius писал(а):
Для этой задачи - ограничить импорт - вовсе не обязательно менять язык. Достаточно инструментального средства, которое будет проверять соответствие (откомпилированного) модуля М вашим правилам. Если очень надо - можно эту проверку сделать в компоновщике-загрузчике.
Но, кмк, вводить отдельный scope для подсистем - не вижу практического смысла и выгоды. Этак можно до friend договориться и раздуть компилятор, замучив компиляторщиков проверками.

Изначально я тоже думал о внешних инструментах. Но - костыль. Модули это часть языка и в языке есть механизм работы с ними. Если вводить понятие "подсистема" то это явным образом должно быть выражено в языке.
Насчет выгод, могу сказать, что сначала посмотрите проблемы подсистемы Host - материалов море и на форуме и на сайте.
Если есть проблема с этой подсистемой, то, уверен, похожие проблемы вылезут и в другом проекте и в другое время. Почему же не решить сразу?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Февраль, 2020 17:10 

Зарегистрирован: Среда, 31 Октябрь, 2007 18:58
Сообщения: 252
Откуда: Austria, Bruck
Rifat писал(а):
Удивительно, но я сам недавно думал над этими проблемами (видимо многие идеи витают в воздухе и считываются из ноосферы :)
...
3) Лично я считаю, что расположение модулей в системе должно быть не одноуровневым и не двухуровневым, а многоуровневым, как дерево (аналогия с методами сверху вниз и снизу вверх). Можно привести аналогию с языком Oberon-07 (и другими Oberon-нами), где разрешены вложенные подпрограммы. В Oberon-07 есть правило, что вложенная подпрограмма может обращаться к своим локальным переменным или же к переменным глобального уровня. Думаю, что что-то типа этого правила можно ввести и для модулей, что модули внутри какой-то папки (подсистемы) могут обращаться к модулям глобального уровня, своего уровня и своего дочернего уровня (но не к подмодулям дочернего уровня).

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

Цитата:
Также нужно продумать то, как легко можно переключаться между вариантами реализации. Думаю, что можно создать один модуль интерфейса, который в IMPORT подключает один из вариантов модуля реализации. Таким образом, можно будет легко менять вариант реализации. Списки модулей, которые надо включить для сборки проекта должны включаться внутрь каждой подсистемы, чтобы на верхнем уровне указывать только включаемые подсистемы, а их списки подмодулей подключатся автоматически.
Пока это еще не завершенная идея, возможно, что-то здесь не совсем хорошо, надо еще думать над этим.

То же размышлял над этим. И тут думаю есть простое решение - механизм "псевдонимов" модулей.
Совсем не обязательно вводить модули заглушки, а можно просто "снаружи" указывать что "МодульА" можно загружать под именем "МодульБ".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Февраль, 2020 22:44 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Как вы понимаете определение и определенность?


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 6 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB