Здравствуйте, Трурль, Вы писали:

Т>Здесь, действительно, нечто иное. Пусть метод класса A вызывает метод класса B, а тот в свою очередь вызывает метод класса A. Тогда класс A должен быть описан до B, а B до A.

Достаточно делать пред-объявление класса как, например, в С++.
Кстати, а что будет, если перекрёстное использование не на уровне методов, а на уровне структур данных? Тут без пред-объявления не обойтись.
Таким пред-объявлением является объявление типа указателя.
Так что можно было и объявления методов запихать в объявление класса.

Впрочем, дело вкуса.
Мне, понятное дело, больше нравится С++, в котором определение метода можно как внутрь запихать, так и наружу вынести (в отличие от Java|C# — где только внутрь, или от Oberon, где только наружу).
Но такие вещи решаются с помощью интеллектуального редактора или препроцессора. Например (благо, синтаксис лёгкий), за один проход перловый скрипт вытаскивает все указательные типы и прототипы процедур и пишет их объявления в начале файла, сразу после импорта. Тогда программист вообще может расслабиться

Здравствуйте, Кодт, Вы писали:

К>C K&R
К>C для разных микроконтроллеров (как правило, на основе K&R)
К>C90
К>C99
К>Objective C (жутковатая помесь Си со Смолтоком)
К>C++ (первая редакция языка, где не было всяких разных фич)
К>C++ (вторая редакция — современная)
К>Java
К>JavaScript
К>Tcl
К>Csh
К>D
К>C#
Ну, тикль с шелл-скриптом по моему, ты зря упомянул. Далековато они находятся от остальных перечисленных...
К>Кого ещё забыл?

Sphinx C-- ?

Здравствуйте, Трурль, Вы писали:

Т>Здравствуйте, Кодт, Вы писали:

К>>У меня сразу же возникает вопрос: а можно ли определять ассоциированную процедуру в другом модуле?

Т>У меня тоже возникал такой вопрос. Интересный язык получился бы.

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

К>>Например, выполняют два прохода — сперва собирают объявления типов и сигнатуры процедур, а затем обслуживают определения процедур.

Т>В Обероне, как и в его предшественниках, все имена должны объявляться до использования. Это сделано для того, чтобы можно было написать однопроходный (и быстрый) компилятор. Современные компиляторы в большинстве своем многопроходные, но ограничение осталось.


Блин, ну, зачем говорить о том, что слабо знаете? Проходы в классике — это считывания исходного файла. Это проблемы давно ушедших времен когда все данные проекта нельзя было разместить в оперативке. На сегодня 99% компиляторов строит AST или триадный код и уже на базе него отрабатывает нужные сематические правила.

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

У того же Шарпа данное ограничение (предекларация) отсуствует, а компилятор получается очень быстрый. С++ тоже был бы быстрый если бы был модульным и не имел столь сложного препроцессора.

К>>Или же имеется в виду нечто иное?
Т>Здесь, действительно, нечто иное. Пусть метод класса A вызывает метод класса B, а тот в свою очередь вызывает метод класса A. Тогда класс A должен быть описан до B, а B до A.

Примитивиская логика. Вот рпимер на Шарпе:

class A
{
    void f1(B b)
    {
        b.f2(this);
    }
    
    void f3() {}
}

class B
{
    void f2(A a)
    {
        a.f3();
    }
}

Все компилируется без каких либо предеклараций и со скоростью звука. Так что примитивизм не необходим.

Здравствуйте, Кодт, Вы писали:

К>Здесь есть неувязка. Если две процедуры перекрёстно ссылаются друг на друга, то заголовок одной из них должен быть продублирован — в пред-объявлении и в определении.

Почему должен? И почему в Яве, Шарпе и ВБ все работает без предеклараций?

К>Почему для обычных процедур мы считаем это нормальным, а для методов — нет?

Я не считаю. По мне так любое дублирование вредно и излишне.

Здравствуйте, Кодт, Вы писали:

К>Кстати, а что будет, если перекрёстное использование не на уровне методов, а на уровне структур данных? Тут без пред-объявления не обойтись.

Почему?

class A
{
    B _b;
}

class B
{
    A _a;
}

Подсунь этот код Шарпу или Яве и убедись, что пролем не возникнет.

Здравствуйте, VladD2, Вы писали:


Т>>В Обероне, как и в его предшественниках, все имена должны объявляться до использования. Это сделано для того, чтобы можно было написать однопроходный (и быстрый) компилятор. Современные компиляторы в большинстве своем многопроходные, но ограничение осталось.


VD>Блин, ну, зачем говорить о том, что слабо знаете? Проходы в классике — это считывания исходного файла.
Вообще-то обход синтаксического дерева тоже называют проходом.

Здравствуйте, Кодт, Вы писали:

К>Решения:
К>- многопроходный компилятор
Это по-моему оптимально, но авторам, видимо, хотелось оставить возможность делать однопроходные компиляторы.
К>- разнести объявление и определение методов.
Тогда бы язык получился несовместимым с Обероном.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Кодт, Вы писали:

К>>Кстати, а что будет, если перекрёстное использование не на уровне методов, а на уровне структур данных? Тут без пред-объявления не обойтись.

VD>Почему?
VD>

VD>class A
VD>{
VD>    B _b;
VD>}

VD>class B
VD>{
VD>    A _a;
VD>}
VD>

VD>Подсунь этот код Шарпу или Яве и убедись, что пролем не возникнет.

Аналогичный код:

TYPE
  A = POINTER TO RECORD 
    b: B;
  END;

  B = POINTER TO RECORD 
    a: A;
  END;

можно подсунуть Блэкбоксу, там тоже никаких проблем не будет.

В данном случае речь идет о процедурах:

MODULE M1;

TYPE
  A = POINTER TO RECORD 
    b: B;
  END;

  B = POINTER TO RECORD 
    a: A;
  END;


(* Предварительное "^" объявление процедуры Bbb() связанной с типом B *)
PROCEDURE^ (t: B) Bbb (), NEW;



(* Объявление и Определение процедуры Aaa() связанной с типом A *)
PROCEDURE(t: A) Aaa (), NEW;
BEGIN
  t.b.Bbb(); (* <--- Вызов объявленной выше, но еще не определенной процедуры Bbb() *)
END Aaa;



(* Определение объявленной ранее процедуры Bbb() связанной с типом B *)
PROCEDURE(t: B) Bbb(), NEW;
BEGIN
  t.a.Aaa();
END Bbb;


END M1.

Да, конечно, предварительное объявление процедуры

PROCEDURE^ (t: B) Bbb (), NEW;

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

Здравствуйте, VladD2, Вы писали:

К>>>У меня сразу же возникает вопрос: а можно ли определять ассоциированную процедуру в другом модуле?

Т>>У меня тоже возникал такой вопрос. Интересный язык получился бы.

VD>Незнаю о том ли ты, но в Руби есть так называемые синглтон-методы. Позволяют переопределять методы у конкретных экземпляров.

Тут речь не о перегрузке у экземпляров, а о том, что полиморфные методы можно определять независимо от классов.
С синтаксической точки зрения, от инфиксной нотации obj.method(args) можно перейти к префиксной method(obj, args).
В принципе, эта задача известна — она возникает, например, при создании мультиметодов без помощи двойной диспетчеризации.
Тут получается вырожденный случай мультиметода — от одного полиморфного аргумента.

Здравствуйте, VladD2, Вы писали:

К>>Здесь есть неувязка. Если две процедуры перекрёстно ссылаются друг на друга, то заголовок одной из них должен быть продублирован — в пред-объявлении и в определении.

VD>Почему должен? И почему в Яве, Шарпе и ВБ все работает без предеклараций?

К>>Почему для обычных процедур мы считаем это нормальным, а для методов — нет?

VD>Я не считаю. По мне так любое дублирование вредно и излишне.

Я имею в виду — в Обероне-2.

Здравствуйте, Трурль, Вы писали:

К>>Решения:
К>>- многопроходный компилятор
Т>Это по-моему оптимально, но авторам, видимо, хотелось оставить возможность делать однопроходные компиляторы.

... утконос и ехидна — отряд однопроходных

К>>- разнести объявление и определение методов.
Т>Тогда бы язык получился несовместимым с Обероном.

Почему? Если Оберон умеет пред-объявлять обычные процедуры, то чем методы хуже?
Писать постфикс "forward" или компонент-паскалевскую птичку "procedure^" — это, в общем, без разницы.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Да, конечно, предварительное объявление процедуры
СГ>

СГ>PROCEDURE^ (t: B) Bbb (), NEW;
СГ>

СГ>приводит к дублированию кода, которое так напрягает... Но, как я уже писал ранее, перекрестный вызов процедур случается редко. Влом что ли пару раз на всю программу написать предварительное определение? Можете привести реальные примеры когда Вы сами пользовались перекрестными вызовами процедур?

Я постараюсь всеми силами сохранить удобный мне порядок следования кода, вытекающий из дизайна программы.
Если для этого мне потребуется пред-объявление чего бы то ни было — типов, процедур, ??? — что ж, напишу их.

Кроме того, лично я (никому не навязываю) считаю удобным, когда все описания выглядят компактно. А, как говорил сам Вирт, программа = структуры + алгоритмы. То есть я хочу видеть структуру объекта рядом с перечнем его методов.
Умеет редактор сворачивать текст определения (как, например, VisualStudio.NET) — прекрасно. Не умеет — буду разносить объявление и определение.

Мне кажется, дело в первую очередь в этом, а не в наличии циклов в графе зависимостей.

Трурль,

> VD> Проходы в классике — это считывания исходного файла.

> Вообще-то обход синтаксического дерева тоже называют проходом.

Есть, по меньшей мере, две терминологии. Одна называет проходом считывание входного файла, обработку, и запись выходного файла, называя пероход от одного внутреннего представления к другому (в т.ч. и обход синтаксического дерева) фазами. Другая называет проходом и то, и другое.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Есть, по меньшей мере, две терминологии. Одна называет проходом считывание входного файла, обработку, и запись выходного файла, называя пероход от одного внутреннего представления к другому (в т.ч. и обход синтаксического дерева) фазами. Другая называет проходом и то, и другое.

Добавлю что преимущество однопроходных компиляторов имеет место быть для первого варианта.

Здравствуйте, Кодт, Вы писали:

К>Я имею в виду — в Обероне-2.

То есть ты о непоследовательности? Или Оберону это простительно?

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Да, конечно, предварительное объявление процедуры
СГ>

СГ>PROCEDURE^ (t: B) Bbb (), NEW;
СГ>

СГ>приводит к дублированию кода, которое так напрягает... Но, как я уже писал ранее, перекрестный вызов процедур случается редко. Влом что ли пару раз на всю программу написать предварительное определение?

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

СГ>Можете привести реальные примеры когда Вы сами пользовались перекрестными вызовами процедур?

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

И вообще, не удобно распологать код в каком-то порядке.

Согласись, что проще не думать о мелочах.

Здравствуйте, Трурль, Вы писали:

VD>>Блин, ну, зачем говорить о том, что слабо знаете? Проходы в классике — это считывания исходного файла.
Т>Вообще-то обход синтаксического дерева тоже называют проходом.

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

Хорошим доказательством того, что количество фаз компиляции мало влияет на скорось компиляции служат компиляторы Явы и Шарпа. Они не уступают по скорости однопроходным компиляторам.

Я могу привести скорость объхода АСТ для R# (на самомо большом проекте). При использовании универсального метода обхода (намного менее эффективного чем обхода на базе визитера) объод занимает ~ 0.05 секунды. При этом парсинг уже закэшированных исходников занимает где-то 0.4 сек. При использовании патерна визитер обход вообще превратится в микросекунды.

Так что на скорость компиляции влияет в основном:
1. Скоростные характеристики семантических правил.
2. Объем обрабатываемого исходного кода.

Например, для С++ оба паказателя крайне велики. И это при том, чтосам язык требует предеклараций.

VladD2,

> Ущербно само требование предварительной декларации.

Всегда? Требование любых предварительных объявлений?

Даже предварительного объявления переменных?

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Павел Кузнецов, Вы писали:

ПК>>Есть, по меньшей мере, две терминологии. Одна называет проходом считывание входного файла, обработку, и запись выходного файла, называя пероход от одного внутреннего представления к другому (в т.ч. и обход синтаксического дерева) фазами. Другая называет проходом и то, и другое.

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

Здравствуйте, VladD2, Вы писали:

К>>Я имею в виду — в Обероне-2.

VD>То есть ты о непоследовательности? Или Оберону это простительно?

Я ничего здесь не прощаю
Фразу "Здесь есть неувязка. Если <> две процедуры перекрёстно ссылаются друг на друга, то заголовок одной из них должен быть продублирован — в пред-объявлении и в определении." нужно читать "... Если <в Обероне-2> две процедуры ..."

Про другие языки я не говорил. Поэтому твой ответ пришёлся не к месту.