OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 19 Март, 2024 09:13

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




Начать новую тему Ответить на тему  [ Сообщений: 31 ]  На страницу Пред.  1, 2
Автор Сообщение
СообщениеДобавлено: Вторник, 24 Апрель, 2018 20:40 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
PSV100 писал(а):
Что-то по поводу SPLang гуглится нечто иное. Видимо, вместо SPLang подразумевается SLang (действительно любопытный, однако), который гуглится на смежной ветке форума:
https://forum.oberoncore.ru/viewtopic.php?f=12&t=6227
Верно, имелся ввиду SLang. Это рабочее название и SPLang тоже рассматривался в качестве временного обозначения.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 25 Апрель, 2018 11:02 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 987
Откуда: Казань
PSV100 писал(а):
...
И вот хотя бы на примере того же ООП на сегодня наблюдается проблематичность создания некоего единого "лексикона" программирования для всего IT -- широкий разнобой в принципах реализации, а также и в базовых теоретических построениях.
...
Короче говоря, на сегодня какой-то глобальный "лексикон" возможен лишь как аля алгоритмическая алгебра у Глушковцев -- некие общие математические построения возможны, но при попытках детализации возникают алгебраические "клоны" (разделы) -- для "структурного программирования" и т.д.

Лексикон он должен быть общим для любых языков программирования. И поэтому его лучше представлять, как язык спецификации программ. Тогда будет, например, компонент на языке X++, и его спецификация на Лексиконе, и компонент, который должен делать то же самое, но на другом языке FunctionalLanguage, и его спецификация на Лексиконе. Реализации могут быть разные, а спецификация должна быть одна. И программисту, достаточно будет посмотреть на спецификацию и понять, что делает компонент и как его использовать, и не надо будет читать N kloc кода для того, чтобы понять, что код делает.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 25 Апрель, 2018 11:37 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Rifat писал(а):
Лексикон он должен быть общим для любых языков программирования. И поэтому его лучше представлять, как язык спецификации программ
Одинаковый язык спецификаций для разных языков сделать не получится, потому что разные понятия языков требуют и разных спецификаций, если речь идёт о полноте, точности, простоте и автоматической проверяемости. Если же не идёт, то такие языки уже есть - это естественные языки общения. Вот Вам и лексикон, хотя и в данном случае о едином языке не идёт, несмотря на одни и те же роли. По схожим причинам и единый язык спецификаций нереализуем.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 25 Апрель, 2018 12:31 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 987
Откуда: Казань
Comdiv писал(а):
Одинаковый язык спецификаций для разных языков сделать не получится, потому что разные понятия языков требуют и разных спецификаций...

Все понятия, наверно, и не требуется включать, так как не требуется описывать устройство, а требуется только описывать поведение компонента. Основное - это булева логика, арифметика. Что еще обязательно нужно включить? Теорию графов?
И, если можете, приведите, какое-нибудь понятие языка, которое ничем иным, кроме этого понятия описать не получится.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 25 Апрель, 2018 18:40 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 987
Откуда: Казань
Вообще есть такая тема, как Unifying Theories of Programming (UTP), где пытаются собрать все абстракции, которые нужны для описания любых программ. В принципе это близко к Лексикону программирования.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 25 Апрель, 2018 23:47 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Rifat писал(а):
И, если можете, приведите, какое-нибудь понятие языка, которое ничем иным, кроме этого понятия описать не получится.
Вопрос с подвохом. Вы можете выбрать для спецификаций полный по Тьюрингу язык с минимальным набором априорных понятий и абсолютно всё описать с помощью него, включая арифметику. Но даже указав на априорные понятие, мы не сможем сказать, что их не получится описать, так как для этого всего лишь нужно опереться на другие априорные понятия. Иными словами, можно выводить хоть сепульки через сепуление, хоть сепуление через сепульки. Но практический вопрос, естественно, не в этом, а в возможности эффективно описывать возможности языков, а для этого нужны понятие этих языков и мы приходим к разным языкам спецификаций.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Апрель, 2018 08:57 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 583
Откуда: Москва
Comdiv писал(а):
Попробуйте на досуге с помощью булевой логики, арифметики и теории графов описать интерфейс метода шаблонизированного класса - наследника нескольких классов, принимающего на вход замыкание и способного бросать исключения.

Отличное предложение! А то что-то все в небесах Лексикон витает.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Апрель, 2018 10:22 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 987
Откуда: Казань
Comdiv писал(а):
Попробуйте на досуге с помощью булевой логики, арифметики и теории графов описать интерфейс метода шаблонизированного класса - наследника нескольких классов, принимающего на вход замыкание и способного бросать исключения.

Это все обертка. А обертка может быть разной. В некоторых языках нет шаблонов, исключений и т.д, тем не менее реализовать функциональность можно будет.
Что должен делать этот класс?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Апрель, 2018 11:43 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Это будет обёрткой, если рассматривать базовым языком некий Лексикон. Если же смотреть со стороны пользователей языка с множественным наследованием, замыканиями и исключениями, то базовым они будут рассматривать именно этот язык и обёртку нужно писать на неком Лексиконе. Всё зависит от того, что во что переводится. Люди зачастую и пользуются языком N, а не L, чтобы выражать семантику в терминах языка N, а не терминах языка L. И введение очередного всеобщего языка L` ничего не изменит. Непониманием этого грешат все создатели якобы языконезависимых интерфейсов и спецификаций. Это ложная идея.

А логику для класса можете придумать любую, главное, чтобы он использовал указанные понятия.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Апрель, 2018 20:08 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 473
Rifat писал(а):
Все понятия, наверно, и не требуется включать, так как не требуется описывать устройство, а требуется только описывать поведение компонента. Основное - это булева логика, арифметика. Что еще обязательно нужно включить? Теорию графов?

Начинать необходимо с азов. Ранее здесь в теме был указан Зверев:
https://forum.oberoncore.ru/viewtopic.php?f=82&t=4963#p85767

У него как раз весь общий лексикон и собран. На его сайте имеется старое изложение информатики (не столь полное как последняя редакция, но всё ключевое имеется):
http://gnzv.narod.ru/books.htm

Кроме терминологии у него представлено фактически основание математики -- введение в теоретико-множественный подход, иерархический, на основе понимания систем -- прежде, чем что-то считать, необходимо определиться с предметом счёта. В этом плане как предшествующие изложения не помешают древние материалы от Уёмова, Поспелова, Рвачёва (были здесь на форуме в смежной теме) для первичного понимания, что есть предметы, свойства и отношения, чтобы, как минимум, не допускать применение таких нелепых терминов как "абстрактные классы" и т.п., популярные в современном и не очень ООП. Или же, к примеру, упомянутые "компоненты" (чьё поведение хочется описывать) -- толком непонятно что это такое в "программной инженерии" в целом и в некоем компонентно-ориентированном программировании в частности (как и размытое понятие модуля). Во всей остальной инженерии под компонентами подразумеваются функциональные объекты (или спецификации) на этапе конструкторского проектирования -- определение ролей для элементов системы (во взаимосвязи). Затем на технологическом этапе проектирования сборки (производства) определяются модули -- конкретные элементы как назначаемые исполнители ролей (модуль может исполнять в т.ч. множество ролей, как и на одну роль могут быть назначены несколько модулей). Между конкретными модулями возникает интерфейс -- средства и правила взаимодействия. Причём подразумевается динамика системы, т.е. между модулями выполняется передача данных (действующие активные объекты как элементы системы осуществляют передачу пассивных объектов -- транзактов в терминах имитационного моделирования). В итоге ещё необходимо постараться для интерпретации распространённых инженерных положений в отношение "программных" модулей.

Кроме теории множеств у Зверева имеются несколько вариантов логик, адаптированная теория графов, семиотика и ещё некоторые базовые дисциплины. В отношении непосредственно моделирования процессов (описания поведения компонентов) более-менее основательно (в рамках как начальных теоретических построений) раскрыто лишь поведение системы с непрерывной семантикой передачи транзактов в полюсно-узловой форме -- обобщены узловые законы Кирхгофа и представлены типовые отношения (между узлами) для движения потоков сил и энергии, возникновения потенциалов и пр.
Причина -- вариаций насчёт непрерывной семантики в природе нет, и принципы моделирования в этой предметке везде одни и те же. Как только возникает какая-то "прерывность", даже для дискретно-непрерывной семантики -- следует мессиво вариантов моделирования. Зверев лишь обозначил предельно абстрактную форму для построения любой алгоритмики -- граф состояний, функциональный граф и их комбинация -- функциональный граф состояний. В дополнение, у него есть абстрактная модель (для понимания, для объяснения предназначения) возникающего в системе такого явления как "управление" -- на базе сети операционных продукций с метапродукциями для порождения и трансформации элементов системы (на основе моделей продукционных правил в "искусственной интеллекте" от товарища Поспелова тех лет, когда всякие Прологи ещё лишь развивались). И уточнена принципиальная форма управления -- гомеостаз от товарища Анохина, что потом трансформировалось в "кибернетическое управление", и сейчас в информатике задаётся как форма косвенного обращения на базе сенсоров, рефоров и пр. (причём это закон в информатике, как любой закон в физике -- в природе управление (и "искусственное" в т.ч.) на каких-то иных принципах существовать не может).

Модели функционирования выше и есть предельно общий лексикон (а точнее под лексиконом необходимо понимать всю информатику Зверева, как минимум), некий "ассемблер", или даже "машкод" -- любая иная модель может быть сведена к ним (а точнее любые прочие модели лишь на них "выращиваются", может быть даже неявно). Прочие любые абстракции (а они необходимы) лишь отдаляются от них (и чем дальше от реальности -- тем сложнее, в чём несложно убедиться на своей шкуре). И нет единого универсального варианта (который бы всех устроил для всех задач) для свёртки/развертки функционального графа и/или состояний (т.е. форм алгоритмов).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Апрель, 2018 20:20 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 473
Rifat писал(а):
Вообще есть такая тема, как Unifying Theories of Programming (UTP), где пытаются собрать все абстракции, которые нужны для описания любых программ. В принципе это близко к Лексикону программирования.

Качество уровня "инженерности" в программном деле на сегодня таково, что не существует некоего аналога теории автоматического управления (ТАУ) как в соответствующей инженерной дисциплине (даже нет единого изложения информатики, наоборот, полно "шедевров", которых даже вредно читать). Поэтому такие теории как UTP останутся лишь частными взглядами их авторов, и в частности благодаря авторитету этих авторов подобные обобщения где-то могут быть задействованы.

Обратите внимание как на альтернативу на "саморазвивающеюся" алгоритмическую алгебру от товарища Гуревича из Майкрософт (впечатление, что это то, что Вы желаете):
Машины Абстрактных Состояний (Машины Гуревича)

Однако, возникает вопрос в практической применимости подобных моделей/теорий. Впечатление, что те же Машины Гуревича есть попытка создать базис для клепания своих "математических" языков программирования/спецификаций (некий сегодняшний жабский Graal, но для математики). Не в курсе, как именно обстоит дело в этих машинах с формальными методами проверок/верификации, тем более с учётом "пользовательских расширений". В плане формальных методов в качестве примера укажу на TLA+ (со своим языком моделирования/спецификаций) -- в частности, в своё время товарища Lamport-а достало разнообразие всяких "алгебр процессов" и непонятки/неудобства прикручивания к ним логик времени - плюнул на них всех и упростил всё "в лоб" для ряда типовых задач (почти как по Звереву), и получил соответствующую премию:
https://en.wikipedia.org/wiki/TLA%2B

Так вот, если присмотреться, то заметно, что у UTP, машин Гуревича и TLA+ начальный базис довольно идентичный -- фактически, понимание системы переходов (функциональный граф или граф состояний по Звереву с надстройками), причём чётко (ну, пожалуй за исключением машин Гуревича, основания там какие-то мутные, всё-таки) выделяются выполняемые работы и передача "предметов труда" (понимание состояний переменных до и после работы), "холостые" работы (не влияющие на изменение состояний по заданным аспектам), различные структурные композиции переходов/шагов и пр. Но даже первичный базис каждый автор изначально адаптирует под возникающие потребности (возможно ситуация могла бы быть чуть иной, если была бы универсальная "ТАУ" для программирования).

Кстати, в ООП понятия выполнение работы и передача транзактов -- крайне размыты, кто-то называет методы как исполняемые, кто-то как отправку сообщений. Вершиной бардака, пожалуй, есть "точки входа" в "мониторы" в task-ах у Ada (и их "акцептирование") -- видимо, чтобы свести концы с концами (верифицировать) ещё нужно постараться перевести модели на нормальный язык:
https://en.wikibooks.org/wiki/Ada_Programming/Tasking

А вот ещё один пример "развивающихся" алгоритмических алгебр от Глушковцев (но "развиваются" они по-другому, в отличие от Машин Гуревича):
Модифицированная алгебра алгоритмов и инструментальные средства обработки формул алгебры алгоритмов

В статейке выше, фактически, тамошняя предельная абстракция, но для задач оценки эквивалентности, преобразований, оптимизаций алгоритмов, причём именно вычислительных. В дальнейшем начинаются необходимые "клоны" (хоть схемы программ Янова и производные). На фоне моделей выше -- существенная разница в форме первичного базиса. А для моделирования взаимодействующих процессов у Глушковцев уже совсем другая алгебра ("инсерционное программирование" -- от "insert" -- погружение активного объекта в среду -- т.е. введение нового элемента системы, при котором изменяется (и вообще определяется) и элемент системы, и сама система -- моделирование/верификация начинается с этого этапа).
О чётком разделении вычислительных алгоритмов и управляющих процессов хорошо сказано в соседнем форуме -- в рамках "предикатного" (и "автоматного") программирования от В.И Шелехова -- коллеги Ершова (если не ошибаюсь) -- ещё один пример "лексикона", рожденного, так сказать, у истоков.
По ходу дела вспоминается ещё один очень привлекательный универсальный лексикон (для выражения поведения системы/компонентов), когда-то также был представлен на этом форуме -- ГрафКонт (видимо, сейчас (или уже вообще) сайт не работает) -- исчисление управляющих автоматов реального времени (благодаря которому, вроде как, российские космические корабли бороздят просторы Вселенной, некоторые, по крайней мере). Причём временные оценки в модели ГрафКонт-а, в принципе то, насколько я помню суть построений, можно воспринимать как бонус (если они не нужны). В модели, напр. в отличие или в дополнение к UTP, иные операции структурной композиции шагов/переходов системы (функциональных задач в терминах ГрафКонт-а) -- следовать позже, строго позже, синхронизация по началу/концу и др. При этом у задач есть понятие "многовходовости" (задание периодов исполнения, регулярных и относительных и пр.). А также к задачам прикрепляется булевый вектор как обобщение условий запуска (символизирующий наличие/отсутствие сигналов или ресурсов и т.п.), но для формальных методов вектора должны быть подготовлены. А если есть желание готовить подобные вектора не вручную, да и в целом оперировать формализмом, близким к языку программирования, то можно смотреть, напр., в сторону Esterel/Lustre (где также неизбежно имеется свой отпечаток или диалект лексикона).

В общем, если оценить (даже поверхностно) все модели для определения поведения выше, то окажется, что модели Зверева окажутся самыми общими (но и предельно абстрактными). А так, в целом, конечно же, гипотетически необходимо иметь единый вектор развития, с уклонами для конкретики задач, как во всех нормальных инженерных областях (а порядок необходимо наводить с самых-самых начал, ибо, к примеру, даже понятие "кортежа" не везде одинаковое, как было отмечено выше в теме).


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 31 ]  На страницу Пред.  1, 2

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


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

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


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

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