суббота, 25 июля 2020 г.

MUMPS2020: О добавляемых операторах

В настоящее время комитетом MDC ведется работа по стандартизации языка MUMPS. В числе коррекций добавляются новые операторы. О них, как участник MDC, и расскажу.

Добавляются операторы:
  • больше или равно >=
  • меньше или равно <=
  • следует после или равно ]=
  • сортируется после или равно ]]=
  • XOR (исключающее ИЛИ) !!
Добавление операторов не связано с добавлением новых возможностей, поскольку все они могут быть выражены имевшимися в языке средствами, а связано лишь с упрощением читабельности текста на языке MUMPS.

Представим себе следование неких элементов в некотором заданном для них порядке. Упрощенно сравнение элемента A в этом порядке с другими (пусть будет B) выражается одним из трех высказываний:
  1. A левее B
  2. A соответствует, или равен B
  3. A правее B
Учитывая, что в языке присутствует оператор отрицания оператора, мы можем использовать лишь первое отношение, поскольку второе и третье являются его отрицаниями. Соответственно, переставив местами операнды или выбрав парный оператор использующий лишь третье отношение мы можем отрицанием получить первые два. Поэтому существует замена операторов, вводимый в MUMPS2020 на имеющиеся:

"Больше или равно" эквивалентен "не меньше"
A>=B --> A'<B
"Меньше или равно" эквивалентен "не больше"
A<=B --> A'>B
"Следует после или равно" эквивалентен отрицанию "следует после" с перестановкой операндов
A]=B --> B']A
"Сортируется после или равно" эквивалентен отрицанию "сортируется после" с перестановкой операндов
A]]=B --> B']]A
Оператор XOR не использует отношений следования, этот логический оператор эквивалентен отрицанию оператора "равно" с нормированием (можно использовать отрицание) операндов:
A!!B --> 'A'='B
На мой взгляд, принимаемый вариант добавления операторов намного более читабелен. Могу предположить, что если бы в языке они присутствовали изначально, то в операторе отрицания оператора могло и не возникнуть необходимости.

Но сам оператор отрицания оператора сохраняется. Комитетом MDC принято предложение одновременно с тем не разрешать отрицание оператора "следует после или равно" и "сортируется после или равно":
']=
']]=
В рекомендации входит трактовать такую последовательность как синтаксическую ошибку и в MUMPSV1 именно так и реализовано. Я же считаю что оператор отрицания оператора и оператор следования независимы друг от друга и запрещать такой синтаксис в MiniM не стал. Хотя построение оператора из 4-х символов и выглядит, конечно, более громоздко. Не вижу препятствий выполнить такую конструкцию. Одновременно с тем в MiniM не поддерживается отрицание операторов
A'>=B
A'<=B
Они очевидно эквивалентны
A<B
A>B
причем без перестановки операндов. В случае же с отрицанием "следует после или равно" и "сортируется после или равно" перестановка операндов необходима.

2 комментария:

  1. Сейчас в Стандарте ничего не сказано о том, что оба операнда логического выражения (a&b, a!b) обязательны к вычислению, но во всех знакомых мне
    М-системах, кроме YottaDB/GT.M, это так.

    Можно ли ожидать, что в новом Стандарте об этом будет сказано явно, а также, что будет стандартизованы новые операторы, работающие по более привычным правилам (a&&b, a||b)?

    ОтветитьУдалить
    Ответы
    1. Приведу копипаст ответа секретаря MDC Рика Маршала.

      In M 2021 v90 §7.2 Expression Tail exprtail, it reads:

      The order of evaluation is as follows:

      a Evaluate the left-hand expratom.

      b If an exprtail is present immediately to the right, evaluate its expratom or pattern and apply its operator.

      c Repeat step b as necessary, moving to the right.

      In the language of operator precedence, this sequence implies that all binary string, arithmetic, and truth-valued operators are at the same precedence level and are applied in left-to-right order.

      As stated, this requires strong evaluation of operands. This is important because of side effects, such as changes to the naked indicator or side effects of extrinsics within expressions.

      Certainly, there are times it would be nice to be able to specify lazy evaluation, but at present Standard M has no syntax to do that.

      Удалить