OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Воскресенье, 24 Сентябрь, 2017 18:53

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




Начать новую тему Ответить на тему  [ Сообщений: 16 ] 
Автор Сообщение
 Заголовок сообщения: x < y < z и другие "мелкие улучшения"
СообщениеДобавлено: Понедельник, 17 Июль, 2017 17:15 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 458
Откуда: Киев
Илья Ермаков писал(а):
Роман М. писал(а):
Ещё помню, что в каком-то компиляторе Ершова применялись slices и даже неравенства вида y < x < z. Немало интересного.

А мне, имхо, такое не кажется интересным. А вполне себе скучной мелочёвкой. Скорее тупиковыми изысками (не считайте за претензии к Ершову) :) Если хочется острых ощущений в плане "slices и неравенств вида...", можно открыть основательную книженцию по алгебре или тензорному исчислению :)


Вещи, вроде сравнения x < y < z, являются, безусловно, мелкими деталями, но смотреть на них можно по разному. Можно делать акцент на том, что они мелкие, и тогда это мелочёвка, а можно указывать на то, что это детали, и, следовательно, являются частями чего-то более крупного и, возможно, важного.

Изучая большое количество ошибочного кода, и размышляя над тем, каким должен быть язык для ошибкоустойчивого программирования, чтобы свести на нет или уменьшить вероятность появления некоторых видов ошибок, я пришёл к выводу, что двойное сравнение может быть полезным.

Так уж устроен человек, что он ошибается, и, порой, в самых нелепых ситуациях. Он может перепутать именя переменных, поменять их местами, изменить типы операций, забыть часть выражения.

Рассмотрим такое выражение: (x < y) & (y < z). Я насчитал здесь 9 возможных ошибок, каждая из которых, конечно маловероятна, но тем не менее такие вещи в больших скоплениях кода встречаются регулярно. Приняв вероятность каждой из них за P op. Получаем вероятность ошибочности всего выражения P expr1 = 1 - (1 - P op)^9.

Теперь взглянем на мелочёвочное изменение: x < y < z. Здесь я насчитал 7 возможных ошибок, причём 3-е из них, касающихся ошибок в операции сравнения и перепутывании местами x и z, менее вероятны, чем аналогичные в предыдущем выражении. Волюнтаристски примем вероятность этих трёх ошибок за P op / 2. Вероятность ошибочности всего выражения P expr2 = 1 - (1 - P op)^4 * (1 - P op / 2)^3
При малом p, соотношение вероятностей ошибок приблизительно P expr1 / P expr2 = 1.6

Модель, конечно, грубая, она, скорее, качественная, чем численная.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 18 Июль, 2017 15:34 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8782
Откуда: Россия, Орёл
Да, резонно.

Только тогда нужно эту штуку делать так, чтобы не вводить синт. неоднозначности (чтоб не падало усложнений в формальное описание языка и в реализацию компилятора).

Например, универсальный оператор ISORD(x, y, z, .....). Только для нестрогого порядка ещё нужен вариант.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 19 Июль, 2017 00:10 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 458
Откуда: Киев
О синтаксической неоднозначности можно было бы говорить в Си, где изначально не было логического типа, но точно не в Обероне.

С точки зрения Оберона такой синтаксис:
expression = SimpleExpression [relation SimpleExpression].
Код:
PROCEDURE Expression;
    SimpleExpression;
    IF lex IN Relations  THEN
        SimpleExpression;
     END
Превращается в:
expression = SimpleExpression {relation SimpleExpression}.
Код:
PROCEDURE Expression;
    SimpleExpression;
    WHILE lex IN relation DO
        SimpleExpression;
    END
Впрочем, я бы предпочёл чуть более сложный, но более подходящий вариант
expression = SimpleExpression [relation SimpleExpression [relation SimpleExpression]].

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

Кстати, по этой же причине я считаю оправданным цикл FOR.
FOR i := start TO end DO
Можно диагностировать ошибку в случае start > end, но нельзя для цикла
WHILE i < end DO


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 19 Июль, 2017 00:20 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 458
Откуда: Киев
Илья Ермаков писал(а):
Но чтобы всё это не превращалось в многолетние циклы ломания копий - изменений в язык - реализации в компиляторах, это уже хотелось бы какой-то подход с семантическим редактором и расширяемым синтаксисом. САПР для ПО ))
Я не против семантических редакторов, но не думаю, что они решают какую-то принципиальную задачу при наличии внятного синтаксиса текстового представления программы. Для языков, где лишняя ";" может привести не к ошибке трансляции, а смене смысла программы - да, но в нормальном языке - нет.

Семантический редактор - это ещё одна форма работы с тем же языком, поэтому его наличие не спасёт от ломания копий.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 19 Июль, 2017 10:43 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 562
Откуда: Казань
Comdiv писал(а):
Впрочем, я бы предпочёл чуть более сложный, но более подходящий вариант
expression = SimpleExpression [relation SimpleExpression [relation SimpleExpression]].

В принципе, таким путем могут получиться "красивые" математические выражения, такие как:
x < y < z
x <= y < z
x >= y >= z
А могут получиться "некрасивые" выражения:
x < y > z
x > y < z


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 19 Июль, 2017 11:35 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 458
Откуда: Киев
Вы не упомянули и такие:
x IS y IN z

Да, я забыл уточнить, что не все формы двойных сравнений должны быть доступны. Это решается:
    1. Либо на уровне семантического анализа, как это в любом случае делается для выражений, вроде 5 IS 6.
    2. Либо выбрасыванием сравнений >, >=. Этот способ не отменяет пункт 1, но имеет то преимущество, что подталкивает к использованию двойных сравнений, где это нужно. Недостатком является необычность сравнений 0 < x, но, к примеру, сишники к такому привычны с их 0 == x, чтобы ненароком не сделать ошибочное присваивание.
    3. Либо усложнением синтаксиса:
    expression = SimpleExpression [ ( (< | <=) SimpleExpression [ (< | <=) SimpleExpression] ) | (relation SimpleExpression )]
    4. Или переделкой синтаксиса:
    inrange = SimpleExpression IN '(' SimpleExpression [>]..[<] SimpleExpression ')'


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 19 Июль, 2017 15:07 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2381
Откуда: Россия, Ярославль
Лучше введите диапазонный тип, тогда не нужно усложнять синтаксис операторов сравнения.
x IN [0.1, 20); x IN [0.1, 20]; x IN (0.1, 20] и т.д.

А вообще это всё мелочно, конечно. Частный случай частного человека. Забивать каждым таким случаем компилятор - плохо.
Общим решением для задачки "нам бы тут новых видов expression чтобы в одну строчку писать" был бы инфиксный вызов любой процедуры, как это реализовано в моих прекрасных экспериментальных ЯП Leaf и Lomo (см. День Оберона 2016) :D


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 19 Июль, 2017 16:38 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 458
Откуда: Киев
Введение диапазонного типа - это, насколько я понимаю, вариация на тему 4-го пункта, и в любом случае потребует расширения, а потому и усложнения синтаксиса.

Про частный случай частного человека не соглашусь, сравнение на попадание в диапазон - это частый случай. И в случае реализации в соответствии с 1-м пунктом, не забивает компилятор.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 19 Июль, 2017 17:01 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2381
Откуда: Россия, Ярославль
Надо различать в компиляторе уровень описания типов/значений и уровень разбора выражений которые друг с другом перемешиваются. Тип ввести проще, от этого меньше последствий и они локализованы, скажем так.

Comdiv писал(а):
в любом случае потребует расширения, а потому и усложнения синтаксиса.

А у вас что, нет усложнения? Правда?
Comdiv писал(а):
сравнение на попадание в диапазон - это частый случай.
Ну вот и надо иметь сущность "диапазон". Не "частый" случай, a < x < y, а обычный такой range тип. Ну, если уж решились на УЛУЧШЕНИЯ (что не факт)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 19 Июль, 2017 17:55 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 458
Откуда: Киев
Пётр Кушнир писал(а):
Тип ввести проще
Не уверен.

Цитата:
А у вас что, нет усложнения? Правда?
Где, у меня? Здесь представлены гипотетические варианты, которые нигде не внедрены. Цель не усложнять синтаксис в принципе не ставилась и нигде не утверждалась. Мой ответ касается конкретно этого:
Цитата:
Лучше введите диапазонный тип, тогда не нужно усложнять синтаксис
Но если всё же будет выбран 1-й вариант, то конкретно синтаксис дествительно не усложнится ни на грамм. Просто квадратные скобочки заменятся на фигурные.

Цитата:
Comdiv писал(а):
сравнение на попадание в диапазон - это частый случай.
Ну вот и надо иметь сущность "диапазон". Не "частый" случай, a < x < y, а обычный такой range тип. Ну, если уж решились на УЛУЧШЕНИЯ (что не факт)

Мне для этого нужно понимать, какие этот тип задачи решает, и какие проблемы создаёт. Желательно с раскладками, похожие на те, которые я привёл в заглавном сообщении. Для меня пока неясна логическая цепочка про необходимость введения типа. Буду благодарен, если объясните.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 19 Июль, 2017 18:48 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2381
Откуда: Россия, Ярославль
Comdiv писал(а):
Мне для этого нужно понимать, какие этот тип задачи решает, и какие проблемы создаёт. Желательно с раскладками, похожие на те, которые я привёл в заглавном сообщении. Для меня пока неясна логическая цепочка про необходимость введения типа. Буду благодарен, если объясните.
Не думаю, что количество слов увеличивает вес мнения. Я вам уже объяснил, что ввести "ещё один тип" проще, быстрее, а изменения будут локализованы и ограничены секцией разбора "value". В вашем случае мы добавляем совершенно новую для Оберона "цепочку сравнений" с изменением в секции выражений сравнения и так далее.

Comdiv писал(а):
Но если всё же будет выбран 1-й вариант, то конкретно синтаксис дествительно не усложнится ни на грамм. Просто квадратные скобочки заменятся на фигурные.
Гладко было на бумаге...

Comdiv писал(а):
Цитата:
Лучше введите диапазонный тип, тогда не нужно усложнять синтаксис
Цитируйте до конца фразы, пожалуйста.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 19 Июль, 2017 19:59 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 458
Откуда: Киев
Довольно странное отношение к словам и весу мнения. Я же не просил отвесить побольше слов, вне зависимости от их значения, а просил объяснить, потому что на основании сказанного мне ничего не ясно.
Пётр Кушнир писал(а):
Я вам уже объяснил, что ввести "ещё один тип" проще, быстрее, а изменения будут локализованы и ограничены секцией разбора "value".
В том-то и дело, что ничего не объяснили, потому что объяснить - это не то же самое, что заявить. Что означает ввести новый тип, переменные и именованные константы этого типа доступны? Если нет, то почему, если да, то какие действия над ними осуществимы, и как это должно выглядеть? Есть ли подтипы у диапазонов или это один общий тип? Почему это проще?

Пётр Кушнир писал(а):
Цитируйте до конца фразы, пожалуйста.
То есть, я неправильно уловил суть, что Вы не хотели усложнять синтаксис вообще, в частности - синтаксис сравнений, а Вас лишь волновало желание не усложнять конкретно синтаксис сравнений? Мне казалось всё же, что Вас интересует именно общая сложность.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 19 Июль, 2017 22:01 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2381
Откуда: Россия, Ярославль
Comdiv писал(а):
В том-то и дело, что ничего не объяснили, потому что объяснить - это не то же самое, что заявить.
Давайте я сейчас к философии обращусь, мол, вы понимаете "объяснить" вот так, а надо-то вот эдак. Странный заход. Вы вот тоже "объяснили" сомнительно. Мол, надо и всё, часто требуется, и ошибкоустойчивость 1.6. Чего, кого? Наверное, надо так же? Зато вы вон какой позитивный, утвердили и всё. А что, логика :shock: же. Если 1.6, то хорошо.

Я вам третий раз говорю, что с точки зрения реализации нового синтаксиса при наличии базового оберона будет проще ввести ещё один простой тип данных, нежели вводить новый для оберона класс синтаксических конструкций (цепочки операций). Потому что изменения кода будут более локализованы и с более предсказуемыми последствиями. Вам объяснять каждое слово? Локализованность изменений? Последствия изменений для компилятора, рантайма?

При этом задача решается, оберон "улучшается".

Не, лично вы можете пихать в язык всё что угодно, много таких было уже, улучшателей оберона.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 19 Июль, 2017 22:18 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2381
Откуда: Россия, Ярославль
На простых примерах всё просто, как тернарный оператор. В своё время весь хабрахабр ныл, что в обероне нет тернарных операторов, ох, что творилось.
Это потому что люди не видели, что может сделать из тернарного оператора настоящий профессионал. И это ещё ладно, там хоть значимая часть на первом месте. А тут вообще не пойми что.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 20 Июль, 2017 00:32 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 458
Откуда: Киев
Пётр Кушнир писал(а):
Вы вот тоже "объяснили" сомнительно. Мол, надо и всё, часто требуется, и ошибкоустойчивость 1.6. Чего, кого?

Нет, конечно, мои слова "двойное сравнение может быть полезным" можно интерпретировать как "нада и всьо", но для этого нужна определённая гибкость. И "соотношение вероятностей ошибок приблизительно равно 1.6 ... модель, скорее, качественная, чем численная" с приведёнными формулами тоже можно превратить в нелепое "ошибкоустойчивость 1.6", но конструктива в этом нет.

Пётр Кушнир писал(а):
При этом задача решается, оберон "улучшается".
При чём тут Оберон? Он есть такой, каким его определил Вирт, всё остальное - не Оберон, хотя не все со мной согласятся. Но это либо обероноподобные языки как Компонентный Паскаль, либо просто языки с влиянием Оберона, как Go.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 20 Июль, 2017 00:48 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 458
Откуда: Киев
Пётр Кушнир писал(а):
На простых примерах всё просто, как тернарный оператор. В своё время весь хабрахабр ныл, что в обероне нет тернарных операторов, ох, что творилось.

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

Я ранее составлял небольшой список рекомендаций - http://comdivbyzero.blogspot.com/2013/06/blog-post.html для своих коллег. Троичная операция там находилась в списке вещей, которые специального разработали, чтобы потом их запрещать использовать. Правда, там я никаких обоснований практически не давал.


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

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


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

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


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

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