Автор Тема: Oberon-07/13: заметки  (Прочитано 22379 раз)

vlad

  • Hero Member
  • *****
  • Сообщений: 1388
    • Просмотр профиля
Oberon-07/13: заметки
« : Январь 13, 2014, 05:12:43 pm »
Буду кидать в эту тему впечатления от переписывания компилятора на оберон. С целью пересмотреть потом на предмет улучшений языка.

vlad

  • Hero Member
  • *****
  • Сообщений: 1388
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #1 : Январь 13, 2014, 05:19:53 pm »
Попытка использовать в параметрах процедур рекорды вместо указательных типов для придания им семантики ненулевых указателей (по примеру С++).
PROCEDURE p(r: Record); (* r не может быть NIL *)

Не прокатило, потому что зачастую требуется перейти опять к указательному типу - чтобы сравнить с другим указателем или чтобы присвоить полю-указателю или чтобы вернуть указатель.  И если в случае C++ это можно сделать (операция взятия адреса), то в случае оберона - нельзя.

Понятно, что операция взятия адреса переменной не аллоцированной через NEW небезопасна, но вот сравнение с другим указателем - вполне безопасно.
« Последнее редактирование: Январь 13, 2014, 05:22:57 pm от vlad »

vlad

  • Hero Member
  • *****
  • Сообщений: 1388
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #2 : Январь 13, 2014, 05:28:05 pm »
Очень не хватает операции проверки типа, совмещенной с получением доступа к этому типу (хотя бы в виде WITH или недокументированного CASE). Из-за этого код становится заведомо неэффективным и подверженным опискам:
IF p IS T THEN
    p(T).field := 123; (вот здесь можно вместо T написать T2 и получить ошибку в рантайме *)
END;

Проверка здесь делается два раза (присвоить поле, если p нужного типа), хотя с точки зрения желаемого результата - достаточно одной.
« Последнее редактирование: Январь 13, 2014, 05:30:04 pm от vlad »

vlad

  • Hero Member
  • *****
  • Сообщений: 1388
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #3 : Январь 13, 2014, 05:35:45 pm »
Единственный RETURN должен быть объявлен религиозным фетишем и убран. Понятно зачем Вирт его хотел, но цель не оправдывает средства. Появление неестественных дополнительных переменных (или функций), многовложенных IF и переусложненных условий не оправдывают желания не допустить неправильного использования множественного RETURN.

P.S. Потом постараюсь привести кусок переписанного кода.

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3010
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #4 : Январь 13, 2014, 06:04:10 pm »
Единственный RETURN должен быть объявлен религиозным фетишем и убран. Понятно зачем Вирт его хотел, но цель не оправдывает средства. Появление неестественных дополнительных переменных (или функций), многовложенных IF и переусложненных условий не оправдывают желания не допустить неправильного использования множественного RETURN.

P.S. Потом постараюсь привести кусок переписанного кода.

У меня есть два замечания:
1) Это таки не просто меняет синтаксис языка, но меняет и его семантику.
2) См. стандарт MISRA по этому поводу (думаю что это такое все знают):
Цитировать
AV Rule 113 (MISRA Rule 82, Revised)

Functions will have a single exit point.
 
Rationale: Numerous exit points tend to produce functions that are both difficult to
understand and analyze.

Exception: A single exit is not required if such a structure would obscure or otherwise
significantly complicate (such as the introduction of additional variables) a function’s control
logic. Note that the usual resource clean-up must be managed at all exit points.

Источник: http://www.stroustrup.com/JSF-AV-rules.pdf
Y = λf.(λx.f (x x)) (λx.f (x x))

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1949
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #5 : Январь 13, 2014, 06:32:51 pm »
В С++ в этом плане проще, потому что есть goto и исключения, в обероне нет ни того ни другого.
Хотя, конечно, множественные выходы из процедуры лучше лишь множественных входов в неё, и от них лучше избавиться. Но как нибудь безболезненно, что ли...
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3010
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #6 : Январь 13, 2014, 08:23:36 pm »
В С++ в этом плане проще, потому что есть goto и исключения, в обероне нет ни того ни другого.
Хотя, конечно, множественные выходы из процедуры лучше лишь множественных входов в неё, и от них лучше избавиться. Но как нибудь безболезненно, что ли...

Не проще :-) Ибо:
Цитировать
AV Rule 188 (MISRA Rule 55, Revised)

Labels will not be used, except in switch statements.
 
Rationale: Labels are typically either used in switch statements or are as the targets for goto
statements. See exception given in AV Rule 189.

Цитировать
AV Rule 208

C++ exceptions shall not be used (i.e. throw, catch and try shall not be used.)
 
Rationale: Tool support is not adequate at this time.
Y = λf.(λx.f (x x)) (λx.f (x x))

Peter Almazov

  • Sr. Member
  • ****
  • Сообщений: 480
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #7 : Январь 14, 2014, 10:09:48 am »
2) См. стандарт MISRA по этому поводу (думаю что это такое все знают):
...
Источник: http://www.stroustrup.com/JSF-AV-rules.pdf
Наконец-то есть возможность не объяснять, почему тело у if, while всегда надо заключать в фигурные скобки.
А просто ткнуть мордой в документ.

vlad

  • Hero Member
  • *****
  • Сообщений: 1388
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #8 : Январь 14, 2014, 02:43:02 pm »
Наконец-то есть возможность не объяснять, почему тело у if, while всегда надо заключать в фигурные скобки.

Просто не надо городить трехэтажные if'ы. Тогда и проблем не будет, которые пытаются решить обязательными фигурными скобками.

P.S. Знаю о таком "правиле", никогда не пользовался, ни разу на грабли не наступал.

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3010
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #9 : Январь 14, 2014, 02:55:36 pm »
Наконец-то есть возможность не объяснять, почему тело у if, while всегда надо заключать в фигурные скобки.

Просто не надо городить трехэтажные if'ы. Тогда и проблем не будет, которые пытаются решить обязательными фигурными скобками.

P.S. Знаю о таком "правиле", никогда не пользовался, ни разу на грабли не наступал.
Аналогично. Единственный раз когда видел такие граблы - это были грабли у человека который хаотично расставлял отступы (то есть каждый отступ имел свою величину отступа, стиль отступов в одной и той же функции был везде разный и так далее). В этот, единственный раз, грабли были найдены и устранены за полчаса.

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

PS. Тем более что эти лишние скобочки можно добавлять/устранять автоматически. Штука то чисто формальная.
Y = λf.(λx.f (x x)) (λx.f (x x))

Peter Almazov

  • Sr. Member
  • ****
  • Сообщений: 480
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #10 : Январь 14, 2014, 03:53:01 pm »
Так, уже есть два умника. Смотрим здесь http://makesystem.net/?p=2028

Цитировать
Rule 59 (required): выражения формирующие тело условных блоков if, else if, else, while, do {…} while или for, должны быть всегда заключены в фигурные скобки, если даже это единственное выражение блока. Это позволяет избежать опасностей при добавлении выражений в условные блоки.

Что такое required, надеюсь всем понятно. Тогда приступим... :)

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3010
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #11 : Январь 14, 2014, 03:56:16 pm »
Так, уже есть два умника. Смотрим здесь http://makesystem.net/?p=2028

Цитировать
Rule 59 (required): выражения формирующие тело условных блоков if, else if, else, while, do {…} while или for, должны быть всегда заключены в фигурные скобки, если даже это единственное выражение блока. Это позволяет избежать опасностей при добавлении выражений в условные блоки.

Что такое required, надеюсь всем понятно. Тогда приступим... :)

Прежде чем ответить, я естественно нашел это правило в оригинале, и прочел.
Y = λf.(λx.f (x x)) (λx.f (x x))

Peter Almazov

  • Sr. Member
  • ****
  • Сообщений: 480
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #12 : Январь 14, 2014, 04:15:12 pm »
Дело в том, что здесь http://www.stroustrup.com/JSF-AV-rules.pdf не стоит required.

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3010
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #13 : Январь 14, 2014, 04:21:50 pm »
Дело в том, что здесь http://www.stroustrup.com/JSF-AV-rules.pdf не стоит required.

Там написано "shall", что такое "shall" написано выше в терминологическом разделе (4.2.1):
Цитировать
Should rules are advisory rules. They strongly suggest the recommended way of
doing things.
Will rules are intended to be mandatory requirements. It is expected that they will be
followed, but they do not require verification. They are limited to non-safety-critical
requirements that cannot be easily verified (e.g., naming conventions).
Shall rules are mandatory requirements. They must be followed and they require
verification (either automatic or manual).

Еще раз - прежде чем что-то писать по теме, я вначале проработал документ и естественно разобрался с терминологией.

PS. Да, я зануда.
Y = λf.(λx.f (x x)) (λx.f (x x))

Peter Almazov

  • Sr. Member
  • ****
  • Сообщений: 480
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #14 : Январь 14, 2014, 04:32:05 pm »
Тогда о чем спор не пойму. О том, что на этот документ надо наплевать?