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

AVC>Вместе с тем, ИМХО, Вирт высказал вполне разумную мысль.

Догмы он свои высказвает. Не более того.

AVC>Локальные (вложенные?) процедуры (в т.ч., конечно, процедуры-функции) в Обероне есть (как, кажется, и во всех потомках Паскаля).

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

В общем, освой любой язык с полноценными локальными функциями и сам поймешь что был не прав.

AVC>Вместе с тем, существует запрет на присвоение локальных процедур процедурным переменным.

Это продолжение маразма. Запрет этот ничем не обоснован. Сегодня многие языки это позволяют и обеспечивают очень хороший результат.

AVC>Возможная причина — при вызове локальной процедуры должна передаваться некая дополнительная информация (дисплеи и т.п.), корректность которой компилятор может обеспечить только при "правильной" последовательности вызовов.

Это поток сознания, а не причина. Передавать локальные функции может даже C# 2.0. А языки вроде Лиспа делали это 25 лет назад. Все что нужно для корректной передачи ссылок на функции — это наличие GC. Он в Обероне есть. Так что единственная причина — это то что Вирт за столько лет не смог вникнуть в то что делали параллельно его конкуренты. Иными словами в чужой опыт.

VD>>Но в язык хорош было бы добавить и другие вещи вроде foreach и т.п.

AVC>Здесь есть опасность вкусовщины.

Здесь есть опасность трепавщины. Я не видел ни одного человека пользовавшегося языками с аналогами foreach, которые бы простестовали бы против этого оператора.

AVC>К примеру, FR, при принципиальном, как мне кажется, согласии с тобой, foreach все же недолюбливает...

Серьезно? Жаль он этого не знает.
На самом деле FR поклонник Питона где foreach называется for-ом, а конструкции аналогичной for-у из С/С++ попросту нет. Так что он не то чтобы не недолюбливает. Он только им и пользуется.

AVC>Какой критерий включения/невключения новой конструкции в язык можно было бы предложить?

Критерия два 1) удобство, 2) осуствие проблем. Уж что, что, а с этим у foreach-а проблем нет. Другое дело, что я согласен с Курилкой, что лучше иметь универсальные средства расширения языка. И согласен с тобой, Виртом и представителями МС с Саном, что как раз этот вопрос довольно спорен. Вот только я лично считаю, что спорен он в основном потому, что те кто о нем спорят сами не пробывали использовать расширяемые языки.

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


VD>С Прологом я правда могу ошибаться, а то что Схема — это клон Лиспа — это 100%.

Ну блин, тогда C# — это клон С, потому что скобочки одинаковые и операторы while, for и прочие очень похожи. Вот примерно так же сопоставимы Лисп и Схема.


V>> В прологе сразу несколько способов метапрограммирования... У него программа — как данные, и в классическом виде это интерпретатор На нем довольно легко свои DSL вводить или обогащать семантику стандартного "решателя".

VD>Ну, и как там реализовать скажем встроенную поддержку ХМЛ?

Так же как и везде — через разработку XML-ридеров и вообще XML-либы. Уверен, что этого добра уже есть тонны. Вот вариантик: http://www.zen37763.zen.co.uk/xml_download.html
Довольно-таки миниатюрный исходник для XML-либы. В нем сама логика занимает где-то четверть, а остальное — база данных преобразований для именованных юникодных и всяких управляющих символов, CDATA и т.д. Валидные XML-структуры хоть и записаны в виде программы, но выглядят как простое перечисление оных... В общем, в сравнении с исходниками XML-либы на C# — небо и земля.

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

Кстати, интерпретаторы на Прологе записываются в форме, очень похожей на нормальную Бэкуса-Наура. Потому на нем удобно прототипировать грамматики (всякие DSL, например ).

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

VD>Думаю, что это же ждет и паттерны. Знать реализацию паттернов будет так же полезно как знание алгоритмов сортировки.

VD>Вот только будет это явно не скоро. Качественная поддержка метапрограммирования еще не вошла в мэйнстрим-яызки. И Сан с МС против этого просто таки борются.

Согласен.

Но главное что я хотел показать, это что паттерны вокруг которых все хороводы пляшут, это не что-то новое, изобретенное недавно. Паттерны, например из книги большой четверки — это такой же Copy-Paste вылизанных типовых решений, как и Copy-Paste кода. Поэтому мне нелепо читать про "новые языки программирования, которые будут поддерживать паттеры, и программирование паттернами", и т.п.

New features in Visual C++ 2025:
...
— Now you can copy-and-paste your code thus reusing good solution rather than reinventing it!
...

VladD2,

M>>Эрланг это позволяет?

VD>Он позволяет написать внешнюю метапрограмму. Это позволяет любой универсальный язык. Когда люди говорят о метапрограммировании в ЯП, то речь идет о средствах самого языка. Таких средств в Эрлэнг нет.

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

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

VD>>Он позволяет написать внешнюю метапрограмму. Это позволяет любой универсальный язык. Когда люди говорят о метапрограммировании в ЯП, то речь идет о средствах самого языка. Таких средств в Эрлэнг нет.

M>Ну так нечестно

Нечестно использовать апелляции к мифическим людям, которые "говорят о метапрограммировании в ЯП".

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

VD>С Прологом я правда могу ошибаться, а то что Схема — это клон Лиспа — это 100%. Так что зайди из под анонима и поставь себе минус сам.

Возьми clisp м запусти вот эту простейшую программу на схеме:

(define (fib x)
  (if (< x 2) 1 (+ (fib (- x 1)) (fib (- x 2)) ))
)

(display (fib 16))
(display "\n")

Читай сообщения об ошибках, думай

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


Кё>Но главное что я хотел показать, это что паттерны вокруг которых все хороводы пляшут, это не что-то новое, изобретенное недавно. Паттерны, например из книги большой четверки — это такой же Copy-Paste вылизанных типовых решений, как и Copy-Paste кода. Поэтому мне нелепо читать про "новые языки программирования, которые будут поддерживать паттеры, и программирование паттернами", и т.п.

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

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

AVC>Вместе с тем, ИМХО, Вирт высказал вполне разумную мысль.
AVC>Причем у меня возникает впечатление, что между "современными" методами расширения языков (например, макросами Немерле) и "классическими" ( =упомянутыми Виртом ) есть существенное сходство.

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

VD>>Вот только из ФЯ я бы в первую очередь брал бы паттерн-матчинг, замыкания и локальные функции (которые почти есть в Обероне).

AVC>Локальные (вложенные?) процедуры (в т.ч., конечно, процедуры-функции) в Обероне есть (как, кажется, и во всех потомках Паскаля).
AVC>Вместе с тем, существует запрет на присвоение локальных процедур процедурным переменным.
AVC>Возможная причина — при вызове локальной процедуры должна передаваться некая дополнительная информация (дисплеи и т.п.), корректность которой компилятор может обеспечить только при "правильной" последовательности вызовов.

Просто нужно реализовать нормальное замыкание, Вирт сказал А но не сказал B. Реально для такого примитивного (извини ) языка как оберон просто нормальные замыкания и фвп (включая лямбду) дало бы очень много. Хотя конечно еще нужна полиморфность функций. Притом синтаксическм Оберон практически при этом не усложнится (можно сравнить с тем же питоном, сложность грамматик вполне сопоставима, а мощность нет).

VD>>Но в язык хорош было бы добавить и другие вещи вроде foreach и т.п.

AVC>Здесь есть опасность вкусовщины.
AVC>К примеру, FR, при принципиальном, как мне кажется, согласии с тобой, foreach все же недолюбливает...

Ну Влад уже сказал про питоновский for
Хотя в этом я вполне могу принять минимализм, не нужно кучу for'ов, хватит и одного достаточно мощного. Гораздо важнее включить те конструкции про которые я писал выше.

AVC>Какой критерий включения/невключения новой конструкции в язык можно было бы предложить?

Это от языка зависит. Тот же оберон я думаю вполне может и без сахара в виде foreach и т. п. обойтись, лучше добавить то что на самом деле повысит мощьность языка.

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

VD>>Он позволяет написать внешнюю метапрограмму. Это позволяет любой универсальный язык. Когда люди говорят о метапрограммировании в ЯП, то речь идет о средствах самого языка. Таких средств в Эрлэнг нет.

M>Ну так нечестно

Мне так вот помнится, что в ерланге есть такая полезная штука, как parse transform. Через нее сделана MNEMOSYNE

-------------------------------------
{parse_transform,Module}

Causes the parse transformation function Module:parse_transform/2 to be applied to the parsed code before the code is checked for errors.
-------------------------------------
То-есть на этапе компиляции вызывается произвольный внешний модуль, который и трансформирует отпарсенные формы во что-то другое

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

FR>>Только модульность это очень мало.
FR>>Все потенциально возможные конструкции конечно не нужно включать, но и минимализм Вирта когда в язык не включены просто необходимые для современного языка конструкции и возможности тоже плохо.
AVC>О каких именно современных конструкциях идет речь?

Параметрические типы.
Функции как fco, ну и, соответственно, полноценные лексические замыкания и лямбды.
Алгебраические типы, кортежи, pattern matching.

Да чего там говорить? В Обероне, кажется, даже интерфейса как языковой сущности не существует. И множественной реализации нет, так ведь?

Можно еще и traits/mixins, кстати, но это на любителя.

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


AVC>>Локальные (вложенные?) процедуры (в т.ч., конечно, процедуры-функции) в Обероне есть (как, кажется, и во всех потомках Паскаля).

VD>Нет их там. Там именно как в Паскле можно обявить локальную функцию между сигнатурой метода и начало его тела.

Со времен Алгола-60 именно это и называется локальными функциями.

VD>Так что единственная причина — это то что Вирт за столько лет не смог вникнуть в то что делали параллельно его конкуренты. Иными словами в чужой опыт.

Удобная позиция: "Если кто-то несогласен со мной, то это исключительно от незнания и скудоумия".
Но у Вирта была возможность поучиться и на собственном опыте. Его первый язык был очень похож на синтаксически подслащенный Лисп.

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

AVC>>О каких именно современных конструкциях идет речь?

K>Параметрические типы.
K>Функции как fco, ну и, соответственно, полноценные лексические замыкания и лямбды.
K>Алгебраические типы, кортежи, pattern matching.

Какие же это это современные конструкции? Наследие 70-х.

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

WR>Этот пример показывает. как меняется решение (и даже формулировка) одной и той же задачи в зависимости от точки зрения. А исторически сформировавшихся точек зрения (языки) уже очень много.
WR>В сложившейся ситуации очень наивно полагать, что некоторый язык программирования займёт верх и заткнёт все остальные куда следует. (слишком много людей придётся переучивать).
WR>Можно ожидать появления такой технологии работы с кодом, которая будет обходить эти различия, равно как и точки зрения на задачу.

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

> Автоматизировать нужно только то что можно автоматизирвоать. В прочем
> принцип разумности он везде будет не лишним.
Ок.

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

> kan>Ок, но мне всё-таки хочется понять, что же в данном (или подобном)
> случае можно придумать "встроенное в язык"?
> В данном ничего. Но это лишь потому, что по сути паттерна тут и нет. Это
> пример банальной инкапсуляции. С тем же успехом можно было бы добавить
> одну функцию.
Тут алгоритма нет, т.е. того, что можно записать на формальном языке. Но вот это и есть суть паттерна!
hint: инкапсуляция — тоже паттерн! Да, он слишком очевиден для ООП-языка, но может быть применён, скажем, в процедурном
языке.

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


В общем, мой тезис я внёс в сабж, нарушив принцип "фидошники сабжей не меняют".

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

K>Параметрические типы.
K>Функции как fco, ну и, соответственно, полноценные лексические замыкания и лямбды.
K>Алгебраические типы, кортежи, pattern matching.

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

K>Да чего там говорить? В Обероне, кажется, даже интерфейса как языковой сущности не существует. И множественной реализации нет, так ведь?

Возможно, имя "Оберон" слишком много означает, что вызывает некоторую путаницу.
Оберон (кроме, разумеется, литературных и астрономических ассоциаций) — это:
1) операционная система (теперь, пожалуй, даже целое их семейство);
2) язык программирования, использованный для создания этой операционки;
3) семейство языков — "дериватов" Оберона (Оберон-2, Активный Оберон, Зоннон; на самом деле таких языков гораздо больше).
В первоначальном Обероне-языке не было (множественных) интерфейсов, но в Активном Обероне и Зонноне есть их аналог — definition. (Т.е. не все "оберонщики" такие же минималисты, как Вирт. )

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

К>Мне думается, что ты копаешь уже совсем в другую сторону
К>Вопрос в паттернах в том, чтобы сделать это всё автоматизированным, т.е. использовать библиотечный макрос или что-то подобное.
К>Какой конкретно для конкретной задачи — решает программист/архитектор.
К>Зачем смотреть на паттерн сразу с разных т.зр. я не совсем понимаю, хотя может кому-то это и нужно


я понял. сейчас всем будет счастье.

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

Интересно. хоть какая-то среда так делает?

Отсюда приходим к выводу, что для Nemerle нужна своя ИДЕ.

Или я неправ?

kan wrote:

> В общем, мой тезис я внёс в сабж, нарушив принцип "фидошники сабжей не
> меняют".
Ай-яй-яй... Порезался сабж однако... было:

Сабжи типа "Паттерны суть слабости языков программирования" суть слабости понимания понятия "паттерн"

В общем ни к чему хорошему нарушение принципа не привело

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

VD>Это поток сознания, а не причина. Передавать локальные функции может даже C# 2.0. А языки вроде Лиспа делали это 25 лет назад. Все что нужно для корректной передачи ссылок на функции — это наличие GC. Он в Обероне есть. Так что единственная причина — это то что Вирт за столько лет не смог вникнуть в то что делали параллельно его конкуренты. Иными словами в чужой опыт.

В принципе, многие реализации Паскаля позволяли (и позволяют) делать замыкания, именно благодаря вложенным процедурам и функциям.
Простейший пример (кстати, из книжки Элджера по... Си++, где он горько сетует, что в Си нет вложенных процедур):

procedure p(n: integer);
  procedure fn;
  begin
    do_something(n)
  end;
begin
  callback(@fn)
end;

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

AVC>В принципе, многие реализации Паскаля позволяли (и позволяют) делать замыкания, именно благодаря вложенным процедурам и функциям.
AVC>Простейший пример (кстати, из книжки Элджера по... Си++, где он горько сетует, что в Си нет вложенных процедур):
<skipped/>

Тут FR уже приводил факт — ну не замыкания это, т.к. контекст с ними не передаётся и действует только внутри функции. Хотя частично похоже

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

AVC>>В принципе, многие реализации Паскаля позволяли (и позволяют) делать замыкания, именно благодаря вложенным процедурам и функциям.
AVC>>Простейший пример (кстати, из книжки Элджера по... Си++, где он горько сетует, что в Си нет вложенных процедур):

К>Тут FR уже приводил факт — ну не замыкания это, т.к. контекст с ними не передаётся и действует только внутри функции. Хотя частично похоже

Давай разберемся; может, я неправильно понимаю.
Как это "контекст не передается"?
callback — какая-то внешняя процедура, мы передаем туда fn, callback вызывает fn, fn использует значение n из своего контекста (откуда же еще?).