OberonCore

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

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




Начать новую тему Ответить на тему  [ Сообщений: 94 ]  На страницу Пред.  1, 2, 3, 4, 5
Автор Сообщение
СообщениеДобавлено: Вторник, 20 Январь, 2009 21:10 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Владимир Лось писал(а):
И Вы всегда взмози отыскать в "макаронинах" текстовки правильное расположение операторов, формирующих обмен по протоколу???


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 20 Январь, 2009 21:21 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
Vlad писал(а):
Владимир Лось писал(а):
И Вы всегда взмози отыскать в "макаронинах" текстовки правильное расположение операторов, формирующих обмен по протоколу???


Я бы согласился, что композита это "новое слово в ЯП" и вообще очень круто, если бы она позволяла гарантировать это самое "правильное расположение операторов" в compile-time. Из описания я понял, что это не так (поправьте, если не так).

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

Vlad писал(а):
А вот правильный дизайн (хоть и "традиционный") такую гарантию (в какой-то степени) позволяет получить.

Я могу считать, что "гарантия в какой-то степени" является аналогом "второй свежести"? :lol:

Vlad писал(а):
Поэтому и отношение конкретно к этому "новшеству" у меня такое сдержанное.

Ни фига себе сдержанность! Да Вы тут у нас просто дежурный "плохой мальчик". Что ни тема - Вы обязательно в позу отрицаловки становитесь... Причём с требованием именно Вам всё доказать и разъяснить ("для понимания"!)...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 20 Январь, 2009 21:31 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Владимир Лось писал(а):
Вы постоянно просите, что бы Вам "разжевали и в рот положили"...


Да, вот такой я ленивый. Если вас это раздражает - не отвечайте на мои вопросы.

Владимир Лось писал(а):
Ну да, а то, что городится огород с UML, BOM-ом, диаграммами а ля Дракон, это Вам - не доказательство?! Сам факт производства таких усилий?


Сам факт говорит о том, что "традиционное" описание в коде несовершенно. Я с этим и не спорю. Но если уж вы предлагаете "новое", то вполне естественно желание увидеть чем оно лучше.

Владимир Лось писал(а):
А "нетрадиционность"-то описания деклараций - В ЧЁМ?


Вам не нравится слово "нетрадиционность"? Назовите "это" как-нибудь по-другому.

Владимир Лось писал(а):
В чёсм ваши сомненья и недоверия? В том, что в языке нужна реализация поддержки и рухнет нужность системы ваших знаний по традиционному вороху средств?


О да, имено этого я боюсь больше всего :) Мне такое уже говорили сколько-то лет назад, а я все пишу на C++. И рад бы сползти с него на что-нибудь более приятное, а ведь нет ничего. Оберон все никак не может обрести мировое господство :)

Владимир Лось писал(а):
Вам не нравится??? - Ваше дело и ваши проблемы! Анализ я за Вас провести у Вас в голове не могу...


Ну и закончим с этим.

Владимир Лось писал(а):
Вот я, например уверен, что - как раз подходит! Там средство для такого описание есть и оно верифицируемо (компайл- + реал- тайм).


Ну вот и перепишите какой-нибудь rfc, если не можете найти более простой пример :)

Владимир Лось писал(а):
Вы можете такое сделать на Си++ или указать на готовое решение? Нет! И не сможете никогда (без изменения кардинального языка Си++).


Сделать что? Я уже показал как пример из описания композиты записывается на C++. Или вам нужно видеть BNF в тексте программы? Тогда это не ко мне, мне нужно "ехать", а не "шашечки".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 20 Январь, 2009 22:07 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Vlad писал(а):
Я бы согласился, что композита это "новое слово в ЯП" и вообще очень круто, если бы она позволяла гарантировать это самое "правильное расположение операторов" в compile-time.

"Полную гарантию даёт только страховой полис" )
Статический анализ может выловить только ряд ошибок - несоответствие грамматик программы и протокола по каким-то потенциально порождаемым цепочкам событий.

Показать эквивалентность двух КС-грамматик, если я не ошибаюсь, NP-полная (если вообще вычислимая) задача.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 20 Январь, 2009 23:15 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Владимир Лось писал(а):
А решение вопроса, мне думается, на более плотном использовании рефлекшна и интеграции со структурами данных компилятора на этапе анализа текста... Просто потому, что правила разбора и анализа можно динамически наращивать правилами описания диалогов. Вот Вам и подход к раскапыванию "правильности" и "уместности" вызовов ( и их аргументов ) обращений к каналам...


Слишком туманно...

Владимир Лось писал(а):
Vlad писал(а):
А вот правильный дизайн (хоть и "традиционный") такую гарантию (в какой-то степени) позволяет получить.

Я могу считать, что "гарантия в какой-то степени" является аналогом "второй свежести"? :lol:


Нет, "гарантия в какой-то степени" это то, что я предпочту вместо рантайм проверок. Потому что рантайм проверки тоже не гарантируют функционирования системы согласно задуманному.

Владимир Лось писал(а):
Ни фига себе сдержанность! Да Вы тут у нас просто дежурный "плохой мальчик". Что ни тема - Вы обязательно в позу отрицаловки становитесь... Причём с требованием именно Вам всё доказать и разъяснить ("для понимания"!)...


И что в этом плохого? Если идея действительно хороша, она только четче обрисуется при критическом взгляде. А если это не идея, а всего лишь тема чьего-то диссера, то туда ей и дорога.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 20 Январь, 2009 23:32 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Илья Ермаков писал(а):
"Полную гарантию даёт только страховой полис" )


Это все понятно. Я отлично "вижу" в чем преимущество BNF нотации для задания грамматики для парсера. Я хочу видеть эту нотацию в коде парсера и я не хочу каждый раз писать этот самый парсер. В случае C++ я беру boost::spirit, описываю грамматику, и вот у меня готовый парсер с "гарантированно" меньшим числом ошибок, чем было бы в случае написания своего парсера.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 20 Январь, 2009 23:40 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Композита - первая ласточка. Я лично хотел бы по-другому. Надо и нужно проще для использования.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 21 Январь, 2009 01:04 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
Vlad писал(а):
Я хочу видеть эту нотацию в коде парсера и я не хочу каждый раз писать этот самый парсер.

Так о том и разговор!
И - в полной аналогии с Вашим любимым Си++ и бустовским спиритом. Наложите на систему записи некий набор стандартизирующих правил и вы уже можете хоть (через хэш от строк описания) тип объекта обозначать...
Чем Вам, например нотация в Композите не подходит?
Я имею претензии к ней в части (пока, что) её (и нотации, и самой Композиты) непригодности к тому, что я перечислил (оптимизация и преобразования)...

Vlad писал(а):
В случае C++ я беру boost::spirit, описываю грамматику, и вот у меня готовый парсер с "гарантированно" меньшим числом ошибок, чем было бы в случае написания своего парсера.

Вы - о каких ошибках?

Vlad писал(а):
Интерфейс описывается BNF нотацией. Ладно. Что это дает? Взаимодействие между компонентами в системе более ясное? Не очевидно.

В ЧЁМ неочевидность? Или неудобность?
Пространство вариантов сужено до взаимодействия только двух участников. Плюс к этому - рассматривается только со стороны сервера... То, что делает клиент - получается полуавтоматически (можно через генератор скелетонов кода на стороне клиента, а можно - почувствуйте благость! - из слим/MSIL/байт-кода, с незаполненными виртуальными функциями, который будет самим сервером и прислан клиенту...)...

Vlad писал(а):
Рантайм проверки? А может лучше дизайн подкрутить так, чтобы необходимость в таких проверках отпала? Или в крайнем случае ассертов понаставить?

Странный Вы какой-то... Может лучше подумать и на машину львиную долю рутины переложить?...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 21 Январь, 2009 08:31 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Владимир Лось писал(а):
Я прекрасно понимаю, что Вы тонко намекаете на автоматический вывод типов в Хаскеле...

Нет, не совсем. Зависимые типы -- это немного другое...
В Хаскелле сейчас начинают экспериментировать с зависимыми типами, но его всё-таки нельзя отнести к этой группе языков.
Языки с зависимыми типами -- Agda2, ATS, Cayenne, Coq (вроде бы относят к этой группе), Epigram...

Владимир Лось писал(а):
Но, в последнее время, я осознал, что простое описание типа аки некоего списочного описания неких сигнатур экспортируемых типом сучностей разной природы неполно и "однобоко"...

Получается интересный парадоксик: деклараративность применять при описании статики получается? - хорошо! Но мне нужна динамика (процесс в развитии)! Декларировать протокол можем? - да - пожалуйста - тем же подобием РБНФ! Но теперь нам и на фиг не нужно описание класса в классическом варианте (набор экспортируемых методов)... :D

Что нам давала декларация типов в классике?
Да, почти ничего! Обычно-то и проверка на совместимость-то типов сущостей происходила по сопоставлению имени типа и по именам наследников... "Структурность" (истинность "принадлежности типу") проверялась на этапе компиляции по наличию в типе соответствующего метода (по сигнатуре). "Своевременность" вызова метода НИКАК нельзя проверить!

Это уже относится к спецификациям программы... Кстати, тут как раз и могут помочь зависимые типы...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 21 Январь, 2009 11:39 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Alexey Veselovsky писал(а):
Geniepro писал(а):
В языках с зависимыми типами неправильная программа не скомпилируется, даже если в ней нет синтаксических ошибок. Вот неправильный алгоритм, и всё тут, так чего его запускать на выполнение... :mrgreen:


Гм. А пример можно? Например для каких-нибудь простых алгоритмов типа сортировки.

И вообще, откуда оно будет знать какой алгоритм правильный а какой нет?

Why Dependent Types Matter -- эта статья, наверное, лучше меня ответит на эти вопросы.
К сожалению, она не только на английском, но ещё и использованный в ней язык программирования (Epigram) черезчур непривычен большинству программистов, многие из которых простой двухмерный синтаксис таких языков, как Occam, Haskell, Python или F# не переваривают, а в этом Epigram использована какая-то экстремальная форма двухмерного синтаксиса...

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

ЗЫ. Я сам пока не имею опыта в теме зависимых типов, только начинаю потихоньку изучать это дело. Приведу, как я сам сейчас понимаю процесс разработки программ с зависимыми типами...

Вот из-за чего были недовольны бейсик программисты паскалем, или более общий случай -- что не нравится "динамическим" программистам в языках со статической типизацией?

"Динамисты" привыкли к тому, что могут сразу же "броситься в бой", начать разработку программы, по ходу дела уточняя или переделывая её. А в языках со статической типизацией программист должен сначала перечислить переменные, указать их типы, то есть провести какой-то анализ задачи, и только потом начать делать программу. (Языки с выводом типов и особенно хаскельного семейства немного облегчают это бремя.)

Зависимые типы ещё более ужесточают начальный этап -- нужно не просто указать тип функции, но и специфицировать какие-нибудь свойства алгоритма. Т.е. фактически нужно выдвинуть некоторую теорему о свойствах функции, и компилятор, являющийся по совместительству системой доказательства теорем, попытается верифицировать реализацию функции.

Естественно, такой подход не поможет в случаях, когда спецификация алгоритма неправильная или неполная -- у компилятора просто не будет информации о том, что должен делать этот алгоритм...
Вот в этом недостаток такого подхода -- от заказчика не добиться вменяемого ТЗ, а если и добьёшься -- оно постоянно меняется. Как тут какие-то формальные спецификации определить, теоремы о свойствах программы выдвинуть?..


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 21 Январь, 2009 17:46 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Владимир Лось писал(а):
Наложите на систему записи некий набор стандартизирующих правил и вы уже можете хоть (через хэш от строк описания) тип объекта обозначать...
Чем Вам, например нотация в Композите не подходит?


Нотация в Композите "не идеальна" тем, что BNF мне не кажется чем-то естественным для описания интерфейса (в отличие от описания грамматики).

Владимир Лось писал(а):
Vlad писал(а):
В случае C++ я беру boost::spirit, описываю грамматику, и вот у меня готовый парсер с "гарантированно" меньшим числом ошибок, чем было бы в случае написания своего парсера.

Вы - о каких ошибках?


Об ошибках в реализации парсера. Все что нужно - направить свое внимание на декларирование грамматики в естественной для этого форме.

Владимир Лось писал(а):
Vlad писал(а):
Интерфейс описывается BNF нотацией. Ладно. Что это дает? Взаимодействие между компонентами в системе более ясное? Не очевидно.

В ЧЁМ неочевидность? Или неудобность?


А в чем очевидность и удобность? :) Попробую подытожить мою критику:
1. BNF нотация в Композите позволяет более точно описать интерфейс (превращая его в протокол). Само по себе это хорошо.
2. Удобство (читабельность) такой нотации на общих примерах не проявляется. Представить специализированный пример лично я не смог и был послан изучать rfc. Отсюда делаю вывод, что если такая нотация и дает результат, то на каких-то специализированных задачах.
3. Правильным дизайном традиционных интерфейсов можно добиться в compile-time того, чего Композита позволяет только в run-time.

Общий вывод пока такой: Композита это интересно, но пока не понятно для чего воплощать ее идеи (конкретно BNF нотацию для описания интерфейсов).

Владимир Лось писал(а):
То, что делает клиент - получается полуавтоматически (можно через генератор скелетонов кода на стороне клиента, а можно - почувствуйте благость! - из слим/MSIL/байт-кода, с незаполненными виртуальными функциями, который будет самим сервером и прислан клиенту...)...


Вы смотрите на идею с точки зрения реализации :) Я сначала хочу проникнуться самой идеей :)

Владимир Лось писал(а):
Vlad писал(а):
Рантайм проверки? А может лучше дизайн подкрутить так, чтобы необходимость в таких проверках отпала? Или в крайнем случае ассертов понаставить?

Странный Вы какой-то... Может лучше подумать и на машину львиную долю рутины переложить?...


Да я всегда первый среди желающих переложить что-то на машину :) Наверное поэтому я все еще пишу на C++, а не на обероне :) И поэтому идея "сходу" наколбасить протокол в BNF, а потом пытаться его соблюсти (без всякой помощи компилятора) мне нравится меньше, чем "подумать" над правильным дизайном (хотя думать конечно труднее, чем сразу колбасить).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Январь, 2009 12:06 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
Vlad писал(а):
И поэтому идея "сходу" наколбасить протокол в BNF, а потом пытаться его соблюсти (без всякой помощи компилятора) мне нравится меньше, чем "подумать" над правильным дизайном (хотя думать конечно труднее, чем сразу колбасить).

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

Уж - пардоньте!...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Январь, 2009 17:13 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Владимир Лось писал(а):
Таки Вы меня конечно извините, но "колбасить код" у меня лично чётко сассоциировалось именно с Си++-сниками...


Язык здесь не причем, такая ситуация будет в любом распространенном языке. Причем С++ не спасает даже высокий порог вхождения, потому что всякие IDE (борландовский билдер - особенно яркий пример) опускают этот порог до нуля. Могу обнадежить тем, что фокус популярности уже давно сместился в сторону C# и всякого Web-ориентированного программирования, так что с C++никами вам придется сталкиваться все реже.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Январь, 2009 19:47 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
Vlad писал(а):
Владимир Лось писал(а):
так что с C++никами вам придется сталкиваться все реже.

Да... Видимо, безвременье, да помноженное на типа кризис...


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

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


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

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


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

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