OberonCore

Читал я про все эти итераторы CLU, правда, не у Лисков, а у Сафонова "Языки и методы программирования на платформе Эльбрус". Не целпяет Самая суть абстрактных типов данных схвачена в сочетании модульности, экспорта-импорта-сокрытия применительно к структурам данных и в расширении типов... Остальное - частности над базисом.

Так всё-таки можно обойтись без глобальных переменных при создании конечного автомата?

В С/С++/Алголе можно, так как там есть статические переменные функций, сохраняющие своё состояние между вызовами.

В чистых функциональных языках это состояние придётся держать дополнительным параметром функции, и придётся дополнительно заботиться о его временном хранении где-то. Это не совсем глобальные переменные, но что-то типа этого.
В других языках, в Оберонах, например, можно сделать так же, но это противоречит духу оберон-мышления... :о) Хотя Илья Ермаков много раз тут уже повторял, что глобальное состояние -- зло... ;о)

Сделайте состояние автомата отдельным параметром-контекстом, объектом, наконец, и не парьтесь... В Обероне можно ещё типизированные сообщения пристегнуть.
Не нужно мудрствовать лукаво.

А если речь идёт о том, чтобы заставить отдельно взятую процедуру функционировать как автомат... То неверно это, в общем случае. Процедуры лучше делать чистыми, а не флуктуирующими по своему эффекту... Допустимое исключение - если за процедурой некий общий, единый, глобальный для системы сервис. Нижележащая операционная система. Система времени выполнения. Ну и т.п.

То есть, если я правильно понял, ответ такой: без глобальных объектов в конечном автомате можно обойтись (деталей я не понял), но лучше всё же их использовать, чтобы процедуры не были флуктуирующими по своему эффекту (а что здесь такого нехорошего?). Что, видимо, совпадает с мнением Вирта:



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

Нет, не так. Сделать КА объектом или явным параметром-RECORD - и никаких глобальных объектов...

А "флуктуирующими" процедуры становятся как раз если за ними находится глобальное состояние их модулей. И это в общем случае плохо, т.к. чистая процедура (эффект которой не зависит от истории вызовов, а только от входных параметров) лучше нечистой.

Согласен, что состояние КА хорошо хранить в записи (объекте -- в смысле ООП).
Мне кажется, что в этой ветке у нас немного по-разному понимается смысл выражения "глобальная переменная". Возможно, отсюда некоторые трудности со взаимопониманием.
Вот например:

Т.е. здесь подразумевается, что все переменные не в стеке -- глобальные.

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

Ну, конечно, если мыслить категориями Фортрана...
Но ведь в современном языке на практике любая нормальная переменная где-то локализована, определена в конкретном контексте, из которого приходит в чистые процедуры через параметры...

Ну, это не всегда так... В АО переменные модуля размещаются в "его" стеке (в самом его начале).

У каждого авторитета своя сфера компетенции. Сколько воды утекло с тех пор как Барбара Л. этим занималась?

Глупо вмораживать в язык то, что легко можно выразить *на* языке.
В случае сомнений действуем по принципу разделяй и управляй.
Что тут сложного...

Глупо вмораживать в язык операторы WHILE-DO, REPEAT-UNTIL, ведь их легко можно выразить с помощью оператора GOTO.
Глупо вмораживать в язык концепции процедур и типов данных, ведь всё это можно легко выразить сплошным ассемблерным кодом...

Изобретая очередной while-сипед для обхода списка, Вы бредёте по лезвию бритвы. Когда-нибудь, совершив нелепую ошибку по невнимательности или от усталости и уничтожив контейнер вместо простой обработки его содержимого, Вам вдруг придёт в голову крамольная мысль, что неплохо было бы всё-таки иметь в языке более удобные абстракции...

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

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

Что касается проблем АТД в чистом виде, то посмотрите Непейводу-Скопина "Основания программирования". Вообще хорошая книжка, передающая в том числе вот это ощущение чувства меры в программировании (а уж Непейвода о формализмах и абстракциях знает побольше любого вашего ФП-шника, и если говорит о проблемах - то послушать стоит...).

Бросайте Вы романтику сверхабстракций... Формальные модели ограничены и неполны. Нужно не прикипать сердцем к одной любимой, а знать им цену и менять сообразно с задачами с лёгкой душой... А Вы всё рвётесь их намертво в основной инструмент вкатать. Каждое такое красивое слово типа "итератор" - это некое абстрактное (т.е. в-голове-появившееся) понятие. Значит, за ним стоят некоторые допущения-предположения-упрощения_реальности (как за любым формализмом). Стоит идти от наиболее слабых допущений, усиливая их по мере реальной надобности... Иначе сами себя в лужу загоняем.

Если вы об обероне (пусть даже и в лице ББ), то *далеко* не легко. Настолько нелегко, что будет легче нагородить кучу невнятных while'ов и ad-hoc структур данных, за которыми не будет видно никакой идеи.

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

Ну и пусть себе используется в библиотеке. Их там куча видов может быть сделана. Что ж, всё в язык клепать надо было?

Я не против итераторов и не считаю их супер-абстракцией (кстати, Rider в паттерне CRM BlackBox-а похожую идею выражает. Точка зрения-доступа одного из потребителей на некоторый контейнер данных). Просто к слову пришлись, в долгодлящемся споре с Geniepro

Ну да, в отрыве от контекста многозначная фраза вышла

Фортран здесь ни при чём.

С помощью записей организуются отдельные сущности программы. Ими, например, могут быть объекты в смысле ООП. Объект - это независимая (или почти независимая) сущность, имеющая процедуры (методы) и состояния (поля), доступные во всём объекте. То есть, в любом месте объекта они могут подвергнуться изменению. Если злоупотреблять использованием таких состояний, то увеличивается риск сделать ошибку. А если учесть наследование, то проблема становится ещё больше (если оно реализовано в одном модуле).

Я хочу сказать, что переменные в записи нельзя назвать локальными. Даже с точки зрения создающего их модуля. Ведь, эти переменные доступны и внутри записи, и снаружи. Это начинает работать только при передаче объекта другому модулю.

А какой из этого всего вывод? Хранить состояние КА в процедурах нежелательно (Ермаков). В полях данных записей/объектов - тоже нежелательно (Соловей). Где же тогда? В глобальных переменных (Вирт)? Тоже, вроде, не лучшее решение, так как состояние КА сможет изменить, образно говоря, кто и когда угодно.

Наверное, лучшим решением была бы новая собственная языковая конструкция КА , куда бы можно было упаковать и передачу состояний через параметры, и инициирование событий, и таблицу переходов. Раз уж КА такая популярная вещь, то чем он хуже цикла, имеющего в Оберонах аж 3-4 разновидности.