Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>>>ALGOL-68 и Modula.

S>>И чем же они ЯВУ, а Си -- нет?

ЕМ>Я не говорил, что C — "не ЯВУ". Я имел в виду, что он Я менее высокого У, чем любой из языков, которые принято относить к ЯВУ.

Вы сказали конкретно вот это:

Цель была прежде всего в том, чтобы раздвинуть возможности C в сторону ЯВУ, не теряя при этом его низкоуровневых качеств.

Т.е. если возможности Си нужно было раздвигать в сторону ЯВУ, значит ЯВУ он не являлся. Если следовать написанному вами.

ЕМ>Принципиальная разница в том, что

Простите очередное бла-бла-бла поскипал, т.к. там нет никакой конкретики.

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

Э... А что этому препятствует в Pascal, Modula-2 и Ada?
Либо вы в очередной раз не смогли внятно сформулировать какую-то мысль, либо я не понимаю, чем Си или C++ в этом вопросе лучше условного Modula-2.

S>>Включение же в список кучи языков с GC для сравнения их с чистым Си -- это от большого ума?

ЕМ>Я не понимаю, отчего Вы так уцепились за GC,

Оно заметно.

EM>который тут вообще не при делах.

Очень даже.
Вот в C++ мы можем иметь дело с шаблоном:

template<class T>
class value_holder {
  T _value;
public:
  ...
};

и в C++ мы вынуждены считаться с тем, является ли T ссылкой или указателем, насколько сохраняется семантика value_holder для этого случая, нужно ли нам что-то предпринимать с классом value_holder, если T -- это ссылка.

Тогда как в языках с GC этих вопросов нет.

S>>Значит вы ничего не знаете.

ЕМ>Я сужу по тому, что Вы пишете о C++. Вы всегда выступали прежде всего за совместимость, универсальность, обобщенность, богатство функционала и т.п., а чтоб за эффективность, экономичность, прозрачность, ортогональность функционала — почти не помню.

Я бы еще понял претензии по поводу эффективности и экономичности (хотя я уже как-то давал в профильных форумах ссылку на использование возможностей современного C++ как раз для экономичности). Но прозрачность и ортогональность-то здесь каким боком?

S>>

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

ЕМ>Вас не насторожило ни слово "реализация", ни это?

Нет. Мы же в реальном мире живем. Если есть некая абстрактная Simula, но нет вменяемой реализации для нее, то сыт не будешь.
Это как сейчас с C++ными модулями. В теории они есть. На практике для очень многих их нет. Хотя в стандарте описаны, да.

ЕМ>то не проще ли было допилить и сам язык, и его реализацию, чтобы устранить самые критичные проблемы?

Полагаю, это опять вопрос к Страуструпу. Но, думаю, своей работой он уже на него ответил.

S>>Макросы же обрабатываются до начала работы компилятора

ЕМ>Так обрабатываются только самые примитивные, тупые макросы. Их реализация в C — отличный пример мертворожденной концепции.

А где макросы не примитивные и не тупые? Рискну предположить, что в Lisp-е или каком-нибудь Nemerle.

ЕМ>Полноценный макрос — это как функция, только выполняется на этапе компиляции в тот момент, когда до него доходит очередь (по тексту или по более сложным правилам), а результатом является порожденный код, который затем компилируется опять-таки в заданном порядке.

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

S>>именно то, что вы описываете, как раз C++ными шаблонами и делается: разбор параметров, сопоставление и т.д.

ЕМ>И сколько лет прошло от появления в C++ шаблонов, которые внезапно оказались Тьюринг-полными, до появления первых робких средств делать этот разбор иначе, как посредством побочных эффектов?

Каких таких эффектов, выражайтесь яснее, плз.

ЕМ>Как у Вас реально поворачивается язык называть все эти костыли иначе, чем уродством?

Я вообще не даю оценок, а прошу показать где обобщенное программирование реализовано лучше и гибче.

S>>как в этом вашем идеальном макрогенераторе решать ту проблему, для которой в C++ добавили специализацию шаблонов (хоть полную, хоть частичную)?

ЕМ>Элементарно. "Макрос" при обработке своего "вызова" анализирует список параметров (напомню, в этой концепции ему доступны все известные на данный момент компилятору типы и значения) и либо порождает соответствующий код, либо выдает сообщение об ошибке. Для вящего удобства и красоты можно добавить третий вариант — "макрос" завершается с результатом "это определение не подходит" (что будет аналогично SFINAE), и компилятор ищет другой макрос с тем же именем и подходящим набором параметров. Чисто технически это не обязательно, можно обойтись первыми двумя путями, а нужные варианты кода порождать вызовом других "макросов", как это принято делать с функциями.

Где такое чудо можно увидеть?

ЕМ>Этот же механизм можно было бы применить и в перегрузках функций, и вместо обширного перечня неявных преобразований с их приоритетами, указывать только допустимые типы и возможные преобразования в явном виде.

В современном C++ практически все это под вашим контролем. За исключением унаследованного из Си неявного преобразования целочисленных типов.