Изменение приоритетов операцийНадо отдать должное Владиславу, он точно заметил слабое место в этой рационализации — приоритеты операций. Логические и побитовые операции имеют разный приоритет. Их объединение сделает приоритет выполнения одинаковым. Что может принести неудобства: // Пример Владислава: MaybeUTF8 := (FirstByte and $С0 = $80) and (NextByte and $С0 = $80); // Паскаль-вариант MaybeUTF8 = FirstByte & 0xC0 == 0x80 && NextByte & 0xC0 == 0x80; // Си-вариант MaybeUTF8 = ((FirstByte & 0xC0) == 0x80) && ((NextByte & 0xC0) == 0x80); // эквивалент со скобками // В каком порядке будет вычисляться это выражение при одинаковых приоритерах «&» и «&&»?
результат = флаг 1 & флаг 2 && флаг 3 Повышение приоритета операций дублированием символа операцииОперация «и», записанная двумя символами «&&», более приоритетна, нежели «&» — c одним символом. При одинаковом их смысле. Очерёдность выполнения операций будет такова:1) флаг 2 && флаг 3 // в первую очередь 2) флаг 1 & результат 1-го шага // во вторую очередь 3) результат = результат 2-го шага // в третью очередьАналогично — для операций «или» и «исключающее или»: результат = флаг 1 | флаг 2 || флаг 3 результат = флаг 1 ^ флаг 2 ^^ флаг 3Если знаки операций записываются словами, то и тут можно попробовать одинаковым операциям назначить разный приоритет: результат = флаг 1 and флаг 2 AND флаг 3 // больше буквы — больше приоритет результат = флаг 1 or флаг 2 OR флаг 3 результат = флаг 1 xor флаг 2 XOR флаг 3Внимательный читатель заметит, что в приведённых выше примерах результат не зависит от порядка вычислений. Но примеры тут даны такие, чтобы иллюстрировать саму идею. Поскольку в будущем языке программирования важно придерживаться единого стиля — так легче постигается язык, то закономерно встанет вопрос о «симметричных» операциях. Об операциях «++», «--», «**» и «//», как более приоритетных вариантах всё тех же операций «+», «-», «*» и «/». Почему бы нет? Непривычно будет поначалу, конечно. Но ведь можно будет сэкономить на скобках. Потом, конечно, встанет вопрос о «==» как более приоритетном варианте «=». Но, позвольте, это ж проверка равенства... Тут стремление к единообразию вон куда нас вывело. Однократного повышения приоритета дублированием символа операции может быть недостаточно. Если встретилось сложное выражение, то такое вполне может иметь место. Как попроще выйти из положения? Повышение приоритета операций многократным повторением символа операцииТам, где можно поставить два символа подряд, можно поставить и три, и четыре — сколько надо:a = b ** c ++++ d /// e // первым выполнится сложение // вторым — деление // третьим — умножение // четвёртым — присвоение f = b * ((c + d) / e) // эквивалентная запись в традиционной формеВ таком случае вообще отпадает надобность в традиционных скобках. Можно ли вообще без них обойтись? Сложности возникают вот где. В C/C++ много операций, записанных двумя и тремя символами, а то и буквами. Например: -> // доступ к члену класса по указателю на объект new // создание динамического объекта ->* // обращение к члену класса по указателю на него <= // логическая операция: меньше или равно >>= // присваивание со сдвигом вправоИ как должна быглядеть Какие идеи? И чтоб попроще! Повышение приоритета операций специальным символомДля приоритета операций можно выбрать какой-то специальный символ. Какой именно, надо подумать. Но пока что для обсуждения выберем «^» — треугольник вершиной вверх, которого нет на клавиатуре.a ^= b ▲▲▲% c ▲▲!= 0 ▲| d ▲▲▲<< 2 ▲▲== e a ^= ((b % c) != 0) | ((d << 2) == e) // эквивалентная запись в традиционной формеКакая запись нагляднее — обсуждаемая или традиционная? Понижение приоритета операций специальным символомПриоритеты операций можно не только повышать, но и понижать:a ▼▼^= b ▲% c != 0 ▼| d ▲<< 2 == eТакой вариант тоже имеет право на рассмотрение. Переопределение операцийПоскольку повышение и понижение приоритета операций затрагивают только форму записи, но не семантику, то в переопределении операций ничего не меняется. Например, записанная двумя символами операция «&» не требует переопределения «&&». Переопределение последней нужно даже запретить.Плюсы и минусыПлюсы:
Вычисление приоритетов в выраженияхФормула расчёта приоритета операции:<итоговый приоритет> = <множитель> * <число приоритетов> + <собственный приоритет>где:
Нужен ли ещё один синтаксический сахар?Когда-то был популярен такой упрёк в адрес Microsoft:Вместо того, чтобы повысить надёжность программ, убрать все ошибки, сделать интерфейс проще и удобнее и убрать тормоза, они добавляют лишние свистки и колокольчики! Кому нужна лишняя функциональность? Лучше бы побороли глюки! И с этой идеей можно предъявить претензии в том же духе: «Сколько можно совершенствовать синтаксис? Зачем нужна ещё одна форма записи? Может, лучше поработать не над формой, а над содержанием?» И в этих словах будет немало истины...P.S. «Ну, за проезд!» Когда-то Владислав напомнил мне анекдот:
В автобусе едет мужик. Достал бутылку водки и стакан, налил себе, поднёс ко рту и застыл в ступоре, вроде как забыл что-то важное. А тут по автобусу идёт контролёр:
Опубликовано: 2018.11.23, последняя правка: 2018.11.27 22:32
Отзывы
В спецификации языка опубликовать API к генератору кода, придумать синтаксис для описания операции (например некую смесь из EBNF и обращений к API). Гейт переводит одно состояние регистра в другое. Действие гейта на регистр можно записать так: G∣R⟩=∣R′⟩
Comdiv: Мне кажется, что если выбирать из описанных выше вариантов, то наиболее доходчивый из них — повышение приоритета повторением символа. Типа «+++». Но это не повод отменять скобки. А Ваш выбор какой? Не трогать традиции, ничего не выдумывать, оставить всё как есть?
Какую задачу решает изменение приоритетов?
Повышение приоритета повторением превращает язык операций в вики-разметку: 2+++1 без пробелов больше невозможны, нужно явно писать 2++ + 1, 2 + ++1 или 2 +++ 1. С точки зрения вики-разметки клавиши ▲ и ▼ на клавиатуре есть. Это скобки. Дело в том, что указание приоритетов в самом выражении (а не в DSL/настройках) вынуждает читателя кода работать стековой машиной. Человеческий мозг — плохая стековая машина. Для повышения человечности нужно переходить от стека к визуальному представлению, что и возвращает нас к скобкам. Вообще, опыт проектирования вики-разметки был очень полезен. Когда постоянно держишь в уме, что количество доступных значков естественным образом ограниченно, волей-неволей переходишь в другие измерения, одно из которых — визуальное. Постепено приходит понимание, что исторически сложившаяся система записи не так плоха, как кажется на первый взгляд...
исторически сложившаяся система записи не так плоха, как кажется на первый взгляд Согласен. Она, по крайней мере, прошла проверку временем.2+++1 без пробелов больше невозможны Возможны, если пожертвовать инкрементом, т.е. за инкрементом закрепить другие символы, а «+» оставить только за сложением.
результат = флаг 1 & флаг 2 && флаг 3 Сиди потом и ищи ошибку — где ты пропустил & или где там один лишний? Вы и я будем придерживаться простых решений, а кто-то нарисует что-то типа:результат = флаг 1 & флаг 2 && флаг 3 && флаг 3 & флаг 2 && флаг 1 & флаг 3Вот Вам и вырвиглаз. У программиста и так куча возможностей всё испортить, зачем давать ещё одну? Просто впишите скобки и все понятно, просто потому, что человек их использует чуть более, чем везде и такой аппарат он получает из других дисциплин, типа школьного курса математики. Просто сравниваем два инструмента и? Плюсы? Не вижу. Минусы? ещё один способ все намудрить, усложнить и запутать. Любой инструмент должен иметь целевую функцию — полезность. Если о ней речь не ведется в принципе, то такой инструмент НЕ НУЖЕН.
a = b ** c ++++ d /// eА что если человек пропустил в конце тяжелого рабочего дня какой-то коэффициент? Например: a = b ** c +++ f + d /// eВсе-таки сделать такой финт со скобками сложней, потому что их нужно две и пропуск одного коэффициента моментом подтвердится как ошибка, также как и пропущенная скобка. А может у меня клавиатура в крошках и один плюс не прожался? a = b ** c +++ d /// eКогда этих плюсов там много они будут сливаться и считать их в сложном выражении это та ещё будет радость. Вы не просто даете возможность выстрелить в ногу. Вы даете пулемет с бесконечным числом патронов.
Во-первых, битовые операции и логические операторы должны изначально иметь различный приоритет, потому что сначала нужно вычислить выражение, а уже потом его сравнивать с результатом другого выражения, и по-другому быть просто не должно. Иначе существование побитовых операций лишено смысла. Разграничение одного от другого наилучшим образом решается просто — логические операторы пишутся словами: and, or, xor, not, а побитовые операции знаками — &, |, ^, ~. Все, это позволяет наилучшим образом их разграничить и улучшить читаемость сложных выражений. Далее, по поводу многократного повторения. Эттттоооо реаааальннноооо моветоооон, господа. И этот моветон самым неприличным образом нарушает принцип максимальной краткости синтаксиса и визуального разграничения операндов языка. Более того, я вообще не вижу никакой проблемы относительно повышения или понижения приоритета операций. Это все всегда и везде ещё с времен, когда программирования не существовало в принципе, решалось путем использования круглых скобок. ВОТ! где им самое место, уважаемый автор. Вот тут то как раз их и нужно применять! Вот здесь то их нужно не лениться ставить. Хотя для ленивых программистов существуют вполне корректные правила, продуманные десятилетия назад, которые четко определяют — какой оператор необходимо выполнять раньше других. Ясно, что сначала нужно умножить, а потом уже делить, сначала сложить, а потом вычитать, сначала выполнить унарные операции, а потом за ними бинарные и так далее. Нет в этом никакой проблемы. Просто нет. И рожать её на пустом месте... ну, лучше на что-либо более осмысленное время потратить. Написать автору можно на электронную почту |
2018/11/26 11:57, ВежливыйЛис