[Oberon-07M] небольшие изменения синтаксиса

[igor]

Если у оператора REPEAT ввести обязательный END, то возможно символ ";" можно было бы вообще убрать из языка (?). Мне кажется этот символ в чём-то является анахронизмом, также как и обязательность скобок у функций без параметров. Или нет?

[Peter Almazov]

Во-первых, аналогия какая-то очень дальняя. Разрешать грязь в исходных текстах? Это грязь не от условий применения (от обстоятельств задач), а грязь на производстве

Во-вторых, это будет прыжок далеко усиливающий обсуждаемый вопрос, но по Вашей мысли.
Что получается из подхода "работать в грязь, и в дождь" применительно ко входным исходным текстам, хорошо известно на примере HTML. Представьте на секунду, что было бы, если бы изначально HTML был бы определён так же строго, как XHTML. Написание анализатора и рендеринга было бы темой хорошей курсовой-диплома. Не то, что сейчас - героический труд по борьбе с полной... ж... которая идёт на вход и которую движок должен быть готов обработать (вместо того, чтобы послать написавшего это).

Про грязь на производстве вопрос неоднозначный. Если грязь допускается без снижения качества готового продукта, то это безусловный плюс в технологии - она будет более дешевой.
А в данном случае я просто не вижу грязи. С точки зрения человека, это точно не грязь. Не вижу также, в чем грязь с точки зрения  определения языка в КП.

[valexey]

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

[Rifat]

Еще в Oberon-07 нельзя ставить точку с запятой после оператора RETURN и его значения. Кто как считает, нужно ли здесь разрешать точку с запятой или я просто неправильно код форматирую? Сейчас я пишу:

  RETURN m
END Proc;

А надо допустим:

RETURN m END Proc;

И тогда понятно, что точка запятая здесь не требуется.

[valexey]

RETURN в Oberon-07 не является statement'ом, он является составляющей составной конструкции. То есть по идее, неплохо бы его и отступами как-то выделять, то есть соглашения о форатировании кода тут должны быть иными нежели в КП например.

Но таки код

Код: [Выделить]

PROCEDURE Foo : INTEGER;
VAR
   j : INTEGER;
BEGIN
   INC(j);
RETURN j END Foo;

Все еще смотрится диковинно. Хотя-я… У этого есть свои плюсы — мы явно видим места где у нас функция завершает выполнение.

[valexey]

C другой стороны сам Вирт придерживается стиля обычного, будто RETURN это все еще не часть синтаксиса процедуры-функции, а обычный statement (взято из language report'a):

Код: [Выделить]

PROCEDURE log2(x: INTEGER): INTEGER;
 VAR y: INTEGER;  (*assume x>0*)
BEGIN y := 0;
 WHILE x > 1 DO x := x DIV 2; INC(y) END ;
 RETURN y
END log


[Илья Ермаков]

А в данном случае я просто не вижу грязи. С точки зрения человека, это точно не грязь. Не вижу также, в чем грязь с точки зрения  определения языка в КП.

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

[valexey]

Ставить всегда вне зависимости от позиции поля.

[Geniepro]

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

А Вам и Вашим сотрудникам это реально мешает в работе на КП/ББ?

И, кстати, почему так и не распространился какой-то единый coding style guide для оберонов? Каждый пишет как попало...

[valexey]

Дас, разброд и шатания примерно как в плюсах.

Видимо потому, что нет общеупотребимых библиотек, стиль которых задавал бы стиль всего остального.

[vlad]

Если у оператора REPEAT ввести обязательный END, то возможно символ ";" можно было бы вообще убрать из языка (?). Мне кажется этот символ в чём-то является анахронизмом, также как и обязательность скобок у функций без параметров. Или нет?

Конечно убрать! В питоне его нет По поводу скобок - однозначно нет. Скобки снимают непоределенность между вызовом и взятием ссылки. Единообразность записи. Кроме того, не хочу, чтобы простое выражение "a + b" могло быть на самом деле вызовом двух функций (как в плюсах .

[Сергей Прохоренко]

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

А Вам и Вашим сотрудникам это реально мешает в работе на КП/ББ?

И, кстати, почему так и не распространился какой-то единый coding style guide для оберонов? Каждый пишет как попало...

Ну, кое-какие указания по стилю имеются в документе Oberon for LPC2000 Microcontrollers, в разделе 10 Programming Conventions and Guidelines. Потом, есть ещё "бьютифаеры", которые автоматически задают стиль.

[Rifat]

Как вариант в языке можно все оставить как есть, а проверку таких часто встречаемых ошибок как точка с запятой после последнего поля в записи или после RETURN возложить на IDE, чтобы IDE бил по рукам (подсвечивал красным), если встретилась такая ситуация, тогда она будет исправлена еще до момента компиляции.

[igor]

Мне кажется этот символ в чём-то является анахронизмом, также как и обязательность скобок у функций без параметров. Или нет?

По поводу скобок - однозначно нет.

Да, наверное Вы правы.

[valexey]

Как вариант в языке можно все оставить как есть, а проверку таких часто встречаемых ошибок как точка с запятой после последнего поля в записи или после RETURN возложить на IDE, чтобы IDE бил по рукам (подсвечивал красным), если встретилась такая ситуация, тогда она будет исправлена еще до момента компиляции.

Для того чтобы возложить что-то на IDE оную IDE нужно иметь :-) Хорошая IDE по сути, является надмножеством компилятора, то есть она понимает синтаксис и семантику кода. То есть весь компилятор кроме кодогенерации разве что. Поэтому IDE будет либо повторять 80 процентов компилятора, либо компилятор должен уметь предоставлять нужную информацию IDE. А про это я уже говорил когда предлагал воткнуть в компилятор возможность вывода AST'a. Это часть того, что от компилятора IDE может потребоваться.