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

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

Дело не в Си-подобности, а в алгоритмах вывода типов.

ВВ>А из-за этого возникает та же проблема, что и с $-строками в Немерле — даже в ресурсник не положишь.

В Немерле это ни разу не проблема. Я на самых ранних этапах знакомства с Немрелом реализовал макрос локализации приложений. Он сам находил такие строки и строил по ним файл локализации который потом можно было заменить. Думаю будет не сложно нагуглить ссылку на эту реализацию.

Надо понимать, что Немерле и $-строки, и "функция" printf — это макросы. А макросы вольны анализировать свои параметры и переписывать код как угодно.

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

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

ВВ>>>Более практической задачей был — "динамический" ML-ный printf, для которого строку формата можно формировать в рантайме.
VD>>А список параметров ты тоже в рантайме формировать будешь?

ВВ>А списка параметров и нет. По сути есть лишь последовательные вызовы функции.

Это булшит. Ты в коде как писать будешь?

ВВ>Ты можешь вызвать функцию так: printf(x)(y) а можешь так: printf(x)(y)(z) — и в обоих случаях произойдет сатурация. Потребуется ли тебе вызвать функцию еще раз или не потребуется — вполне может определяться в рантайме.

Еще раз задаю вопрос. Ты этот код будешь писать в исходном файле или ты как-то чудесным образом будешь формировать список аргументов в рантайме?

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

ВВ>Реальной задачей может быть и разработка системы исчисления на основе парочки комбинаторов. Или доказательство теорем. Или написание примерчиков для rosettacode. Так что define "реальная".

Это треп. Для описанных задач есть специально предназначенные для этого решения.

ВВ>Для большинства "реальные задачи" с разработкой компиляторов и веб-фреймворков тоже не связаны.

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

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

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

ВВ>(Я понял, тебе не нравятся Y-комбинаторы. Приведи тогда три своих любимых комбинатора, их и обсудим).
ВВ>По существу — в рамках нетипизированного лямбда-исчисления делать ничего не надо. В рамках типизированного — чтобы записать его именно так, как я, а не через жопу, как это обычно делается, должна быть поддержа эквирекурсивных типов, о чем мы, собственно, тут и говорим.

Мужик, ты говоришь глупость. С точки зрения теории, нетипизированное лямбда-исчисление выводится из типизированного путем введения одного АлгТД описывающего объединение всех типов. Так что все следствия что можно вывести из нетипизированного лямбда-исчисления точно так же можно вывести из типизированного.

Вопрос только в том, что в теории теория и практика одинаковы, а на практике — нет.

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

ВВ>>Реальной задачей может быть и разработка системы исчисления на основе парочки комбинаторов. Или доказательство теорем. Или написание примерчиков для rosettacode. Так что define "реальная".
VD>Это треп. Для описанных задач есть специально предназначенные для этого решения.

Треп — это рассуждение о "реальных задач" без всяких попыток хоть как-то это конкретизировать.

ВВ>>Для большинства "реальные задачи" с разработкой компиляторов и веб-фреймворков тоже не связаны.
VD>Это к делу не относится. В любой программе потребуются вызовы функций и почти в любой пригодились бы макросы и лямбды. Мне же интересно где могут пригодиться описываемые извращения?

Какие извращения? Каррированные функции? Комбинаторы? Эквирекурсия в типах?

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

Ну как же нет. Для функциональных языков системы типов самым явным образом на типизированном лямбда-исчислении и строится. Для императивных — да, основание весьма косвенно. Но причем тут императивные языки?

ВВ>>(Я понял, тебе не нравятся Y-комбинаторы. Приведи тогда три своих любимых комбинатора, их и обсудим).
ВВ>>По существу — в рамках нетипизированного лямбда-исчисления делать ничего не надо. В рамках типизированного — чтобы записать его именно так, как я, а не через жопу, как это обычно делается, должна быть поддержа эквирекурсивных типов, о чем мы, собственно, тут и говорим.

VD>Мужик, ты говоришь глупость. С точки зрения теории, нетипизированное лямбда-исчисление выводится из типизированного путем введения одного АлгТД описывающего объединение всех типов. Так что все следствия что можно вывести из нетипизированного лямбда-исчисления точно так же можно вывести из типизированного.

Если ты о том, что нетипизированное лямбда-исчисление можно рассматривать как частный случай типизированного — то да, это в принципе верно. Только я не о том. А о том, что типизированное лямбда-исчисление это сферический конь. Реальные же системы типов весьма ограничены. Мы же говорили о том, что нужно в языке, чтобы писать функции-комбинаторы, какие в голову придут? В динамическом — ничего кроме функций не нужно. В статическом — надо "излишне усложнять" систему типов, как ты выражаешься.

VD>Вопрос только в том, что в теории теория и практика одинаковы, а на практике — нет.

Мысль, конечно, верная, но к чему это?

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

ВВ>>А списка параметров и нет. По сути есть лишь последовательные вызовы функции.
VD>Это булшит. Ты в коде как писать будешь?

Так и буду писать. Функций, принимающих несколько аргументов просто нет. И это не булшит. И, кстати, это весьма сильно меняет все.

ВВ>>Ты можешь вызвать функцию так: printf(x)(y) а можешь так: printf(x)(y)(z) — и в обоих случаях произойдет сатурация. Потребуется ли тебе вызвать функцию еще раз или не потребуется — вполне может определяться в рантайме.
VD>Еще раз задаю вопрос. Ты этот код будешь писать в исходном файле или ты как-то чудесным образом будешь формировать список аргументов в рантайме?

Легко:

let printf' = printf fmtString x y

let _ | <some condition> = printf' z
| else = printf'

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

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

VD>Что это за язык?

Actionscript 3.0 Диалект ECMAScript с типами и классическими объектами (наследование, интерфейсы и т.п.).

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

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

M>>Вот что-то в подобном роде используется в реальном коде. Обработчики 'about-dialog', 'format-drive-dialog' и т.п. могут находиться в различных подгружаемых модулях, описываются в конфиге.

VD>Программирование на конфигах? А ради чего?

Пока не программирование. Там циклов нет, а только декларативно описывается "дерево" сервисов. Крупных целей две:
1. Изначально все это разрабатывалось под динамическую загрузку диалогов (модулей). Т.е. что-то подгружается только при первом использовании. Приложение — web, flash, так что заставлять пользователю на плохих каналах все грузить не очень хорошо. Ну и наш трафик жалко (считали, много выходит).
2. Отвязка от "глобальных" переменных. Например, диалог должен иметь доступ, например, к показу/скрытию попапов, новых диалоговых окон и т.п. Тот же диалог при этом может запрашивать какие-то данные из приложения, вызывать сервисы и т.п. Я рассматривал типизированные интерфейсы вроде showAboutDialog(aboutDialogDeps : IAboutDialogDeps), но не понравилось. Где-то параметров большое число получалось. Много писанины для каждого модуля в описании его зависимостей и в написании "реализации" этого интерфейса. При существующей схеме я могу просто "ограничить" существующее подмножество "основных" сервисов. Могу в конфиге на входе в модуль (защита от опечаток), могу при передаче в вызов (защита от злонамеренных модулей). Да и возникают проблемы, где размещать интерфейс вызова этого модуля (см. пункт 1). Динамику запускать и проверять нужно, но на интерфейсах я бы тоже запускал и проверял этот же вызов, так что потерь особых нет.

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

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

M>Пока не программирование. Там циклов нет, а только декларативно описывается "дерево" сервисов. Крупных целей две:...
M>Ну и еще для одного из модулей изначально предусматривалось несколько различных реализаций (для различных площадок), так что что-нибудь конфигурировать все равно пришлось бы.

Ну, то есть вы сами выбрали проектное решение которое подсадило вас на динамику. При этом задача в общем-то решалась и статически?

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

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

FR>>Этот шаблон порождает полноценную функцию полностью совпадающую по типу с ее функцией аргументом, с ней можно делать все что можно делать с любой другой функцией. Тут чуть разъясню, шаблоны D в отличии от шаблонов C++ могут порождать любые типы, а не только структуры/классы или функции.

M>Я не про то. Я сам exceptionProtect хочу иметь как first-class object. То, что его результат является функцией — понятно. Например, можно было бы exceptionProtect в Array.map передать или куда-нибудь еще.

Ну такое возможно если Array.map тоже шаблон, и в том же D есть такая штука как Template Alias Parameters которая облегчает такое использование.

M>Другой "шаблон" построить в рантайме и т.п.

А вот это вряд-ли когда-нибудь будет в языках типа C++/D. Мне кажется полноценно это реализуемо только в динамически типизированных языках.

M>И вот как раз полноценной работы с типами мне хватило бы. Причем передачи AST мне ни в один шаблон не нужно. Туда передаются значения разной природы. Это могут быть объекты, это могут быть функции и на выходе как-то строится тип результата. Т.е. "более типизированная" "динамика". В принципе, возможность работы таких "шаблонов" в рантайме упирается в необходимость хорошего RTTI, возможность порождать описания типов в рантайме и "динамический" способ вызова функции.

Есть подозрения что в результате получится разновидность лиспа типа Dylan.