В паскале остро не хватает операторов &, &&, | и ||

Общие вопросы программирования, алгоритмы и т.п.

Модератор: Модераторы

Аватара пользователя
Cheb
энтузиаст
Сообщения: 994
Зарегистрирован: 06.06.2005 15:54:34
Контактная информация:

В паскале остро не хватает операторов &, &&, | и ||

Сообщение Cheb »

В паскале остро не хватает операторов &, | (однозначно побитовые) и &&, || (однозначно булевы)
Почему: and и or убоги тем, что не позволяют писать логические выражения без костылей-скобок.
Ежели бы добавить хотя бы && и ||, которые чётко скажут парсеру: boolean or GTFO
то можно было бы уменьшить количество геморроя.

if (a > 0) and (b > 0) then
супротив
if a > 0 && b > 0 then

Тем более, что символы & и |, ЕМНИП, вообще в языке не используются.

- что думаете? :mrgreen:
Awkward
новенький
Сообщения: 53
Зарегистрирован: 18.01.2017 23:06:47

Сообщение Awkward »

Во-первых, амперсенд & используется.
Во-вторых, думаю, непрактичная идея. То, что есть, на мой личный взгляд даже удобнее. по крайней мере, я не путаюсь, где надо одиночный знак, а где двойной ставить.
Аватара пользователя
vitaly_l
долгожитель
Сообщения: 3333
Зарегистрирован: 31.01.2012 16:41:41
Контактная информация:

Сообщение vitaly_l »

Cheb писал(а):что думаете?

Переопределите операторы, напишите к ним обработчик и...
"мучайтесь" :wink: с "новыми" операторами &,&& и |, ||.
:roll: Никто же в Паскале не запрещает переопределить все операторы?

PS: программисты совсем обленились... скобочки им лень поставить. :cry: :evil:
zub
долгожитель
Сообщения: 2889
Зарегистрирован: 14.11.2005 22:51:26
Контактная информация:

Сообщение zub »

& используется.
Раньше тоже "мучился" потом привык. Сейчас считаю (a > 0) and (b > 0) лучше чем a > 0 && b > 0
Аватара пользователя
alexs
долгожитель
Сообщения: 4066
Зарегистрирован: 15.05.2005 23:17:07
Откуда: г.Ставрополь
Контактная информация:

Сообщение alexs »

Cheb
В нормальных человеческих языках нет таких символов. А паскаль должен быть похож на человеческий язык.
Аватара пользователя
Дож
энтузиаст
Сообщения: 900
Зарегистрирован: 12.10.2008 16:14:47

Сообщение Дож »

На самом деле если бы изначально у операторов and и or был самый низкий приоритет, жилось гораздо лучше. Мне кажется, что какой-нибудь MODESWITCH, занижающий приоритет, был бы хорошим решением.

a > 0 && b > 0 гораздо лучше, чем (a > 0) and (b > 0), но если тупо ввести вторую разновидность оператора and, просто с другим приоритетом, то это излишне усложнит язык.

В нормальных человеческих языках нет таких символов. А паскаль должен быть похож на человеческий язык.


Согласен! Нужно пойти дальше:

Код: Выделить всё

// не по-человечески:
P = ^T;
comment по-человечески
P is pointer to T end of statement

// не по-человечески:
a := @b;
comment по-человечески:
a assign from address of b end of statement

// не по-человечески:
f(a + b);
comment по-человечески:
call f with parameter a plus b end of statement


Паскаль должен быть похож на человеческий язык!
Аватара пользователя
vada
энтузиаст
Сообщения: 691
Зарегистрирован: 14.02.2006 12:43:17

Сообщение vada »

Этак можно дойти и до того что код в комментариях { } писать захотят!
ЗЫ. Некоторые пытаются завышать линию талии. Вот с этим мы будем нещадно бороться! (с)
java73
постоялец
Сообщения: 257
Зарегистрирован: 21.11.2013 09:08:10

Сообщение java73 »

и LINQ )))))))
скалогрыз
долгожитель
Сообщения: 1804
Зарегистрирован: 03.09.2008 02:36:48

Сообщение скалогрыз »

Cheb писал(а):В паскале остро не хватает операторов &, | (однозначно побитовые) и &&, || (однозначно булевы)
Почему: and и or убоги тем, что не позволяют писать логические выражения без костылей-скобок.

- что думаете? :mrgreen:

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

на самом деле, можно предположить, что в язык добавлены | и & - однозначно побитовые, а "or" и "and" оставлены для однозначно булевых.

НО если, такие операторы добавлены, ТО тебе нужно определить с каким приоритетом они идут:
т.е. выражение a or b | c это:

Код: Выделить всё

(a or b) | с

или

Код: Выделить всё

a or (b | c)

В отличии от С-образных языков, паскаль наслаждется всего 5ью уровнями приоритетов операторов. (если кто хочет, то можете погуглить "period table of perl operators").

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

я часто вижу выражения, вроде:
(a * b)+c
люди делают это для себя. Они прекрасно помнят из школьного курса что умножение идёт вперёд (и компилятор тоже это понмнит), но тем не менее пишут же... для наглядности.
Аватара пользователя
Дож
энтузиаст
Сообщения: 900
Зарегистрирован: 12.10.2008 16:14:47

Сообщение Дож »

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

«Наслаждается»? Звучит так, будто 1 уровень приоритетов был бы абсолютным наслаждением :)

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

Вывод ошибочен, при использовании С++ многие не используют скобок (я, например) и ног отстрелить не боятся.
скалогрыз
долгожитель
Сообщения: 1804
Зарегистрирован: 03.09.2008 02:36:48

Сообщение скалогрыз »

Дож писал(а):«Наслаждается»? Звучит так, будто 1 уровень приоритетов был бы абсолютным наслаждением :)

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

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

не бояться <> не отстрелить
;)
но всем и всегда очень легко говорить "за себя". Проблемы выскакивают при работе в команде, или при поддержке старого/чужого кода.
Аватара пользователя
vitaly_l
долгожитель
Сообщения: 3333
Зарегистрирован: 31.01.2012 16:41:41
Контактная информация:

Сообщение vitaly_l »

скалогрыз писал(а):писать программу нужно не до того момента, когда в неё ничего уже нельзя добавить, а до того момента, когда из неё ничего нельзя убрать

У художников, наивысшей формой искусства считается "чистый лист". :roll: Судя по вышеприведённому утверждению - чистый лист является идеальной программой, постольку поскольку оттуда уже нечего убрать! :wink:
Аватара пользователя
Дож
энтузиаст
Сообщения: 900
Зарегистрирован: 12.10.2008 16:14:47

Сообщение Дож »

ну... в ассемблере всего один уровень. (лол, т.к. одна операция)

И как там, здорово писать программы на ассемблере? Как там у него обстоят дела по части отстрела ног, читабельности, поддержки старого кода, работы в команде? Надо полагать из контекста, по всем параметрам выигрывает у страшного и ужасного C++, да?

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

Что скажете за себя? 5 уровней приоритетов — это идеал или нет? 1 уровень лучше?

Можно же не останавливаться на 1 уровне, а пойти и ещё дальше: ошибкой компиляции обязать везде ставить скобки! Например, для выражений вида a * b + c выдать неаккуратному программисту «Fatal Error: Ambiguous operators order.»
Аватара пользователя
vitaly_l
долгожитель
Сообщения: 3333
Зарегистрирован: 31.01.2012 16:41:41
Контактная информация:

Сообщение vitaly_l »

Дож писал(а):обязать везде ставить скобки! Например, для выражений вида a * b + c выдать неаккуратному программисту «Fatal Error

Кстати, скобки там ставятся, только для того чтобы, компилятор не спутал and вот так например:

Код: Выделить всё

if (a > 0 and b) > 0 then

ИМХО, ЛОЛ
Аватара пользователя
Лекс Айрин
долгожитель
Сообщения: 5723
Зарегистрирован: 19.02.2013 16:54:51
Откуда: Волгоград
Контактная информация:

Сообщение Лекс Айрин »

vitaly_l писал(а):У художников, наивысшей формой искусства считается "чистый лист".


Это устаревшее мнение... наивысшей формой искусства считается точка на чистом листе.
Ответить