Oberon space

Цитировать

И да, самое главное — новому ядру Линусом было присвоено кодовое имя «Linux for Workgroups», по аналогии с Windows 3.11 for Workgroups.

Это он зря провёл такую аналогию. Теперь получается, что Linux отстаёт в своём развитии от Венды лет так на ...дцать. 

Шойгу недавно ведь назначили на этот пост, и ему нужно как-то проявить себя. Вот он и.. Эдакая PR-акция конкретно Шойгу, чтобы его запомнили.

Если это действительно так, то цели изначально ложные.
От того, что всадник начнёт энергичнее подпрыгивать в седле, лошадь быстрее не поскачет.

Цитата: valexey_u от Июль 10, 2013, 07:21:41 pm

Вот у меня процедура Foo, которая использует другую процедуру которая определена где-то далеко внизу. Вопрос - как за один проход такое компилировать?

Никак. Просто потому, что в общем случае нельзя "угадать" сигнатуру - оберон допускает неявные преобразования типов аргументов. Например f('A') может быть как вызовом "PROCEDURE f(c: CHAR)" так и "PROCEDURE(s: ARRAY OF CHAR)".

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

Утверждение, что в этом случае "компилятор железно перестаёт быть однопроходным" не верно.

Для сомневающихся хочу дать некоторые пояснения. Я использовал специальную структуру данных, которую назвал "буфер отложенных объявлений". Основная идея в упрощенном виде выглядит так. Парсер делает один проход по исходному тексту. Если парсер в операторной последовательности встречает неизвестный идентификатор, то он панику не разводит, а помещает этот идентификатор в буфер отложенных объявлений. Затем, если далее по тексту встречается объявление этого идентификатора, то парсер переносит его из буфера в таблицу имён. К тому моменту, когда будет достигнут конец модуля, буфер должен быть пуст, иначе ошибка. На самом деле всё несколько сложнее из-за вложенности областей видимости, но в моём случае (обероноподобный язык, но не Оберон) задача алгоритмически вполне решабельна (проверено на практике).

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

Мощно сказано. Спасибо, посмеялсо. Вы хоть бы брали в кавычки слово "понимать". 

(кроме того, название Oberon-07/11 по факту придумано сообществом, сам Вирт его называет просто Oberon - просто это самая свежая ревизия яп. оберона - полная, не урезанная версия)

Самая свежая, пожалуй, Oberon-12 (по моим данным от 01.07.2012).

Хорошо. Давайте зайдем с другой стороны. Какой практический смысл в перекрытии предопределенных идентификаторов (помимо конфуза читающего потом этот код)?

Допустим, в языке введён предопределённый идентификатор Pi, который означает константу "число пи". А некий программист Вася вообще не знаком с тригонометрией  , но ему позарез нужен этот идентификатор для чего-то своего. Он пишет своё объявление Pi, которое автоматически перекрывает предопределённое, и никаких проблем не возникает (по крайней мере до тех пор, пока ему не понадобится число пи).

Что касается идентификатора INTEGER, то я бы его сделал ключевым словом. Возможно, Н.Вирт не хотел портить численные характеристики своего языка (раздувать список ключевых слов) 

Мне было проще по-другому. Мало того, я считаю, что по-моему - правильнее

Возможно. Не вижу смысла с Вами спорить. Всё, что сказано выше мной, - это просто моё мнение.

Цитата: igor от Июнь 18, 2013, 06:01:25 pm

Предопределённые идентификаторы можно представлять себе как идентификаторы, объявленные в неком гипотетическом протомодуле, в который вложены все остальные модули.

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

При компиляции модуля в процессе инициализации создаётся новая область видимости, затем туда добавляются все предопределённые идентификаторы, и потом уже выполняется всё остальное. То есть предопределённые идентификаторы обычно включают не в "каждую новую область видимости", а в область видимости каждого модуля. Это не одно и то же, потому что свои scope есть и у процедур и функций (у блоков). Так как все блоки могут находиться только в модулях, то получается, что предопределённые идентификаторы видны отовсюду, и, следовательно, могут быть перекрыты в любом блоке.