Вышел UHC 1.0.0

>> преобразовывал всё это к функциональной записи *только если это действительно надо*, а если не надо -- оставлял во вполне императивном виде

> вот этого мне в упор не понять. я понимаю, зачем может быть нужно наоборот, но не это. видимо, недорос

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

>Настоящая декларативность -- это когда результат трансформации декларативного кода в императивный код НЕОДНОЗНАЧЕН и скорее всего допускает нетривиальные оптимизации, выполнение которых "напрямую руками" затруднительно, нечитабельно, легко может привести к ошибкам

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

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

> вот как я после подобных должен серъёзно к тебе относиться и пытаться понять твои идеи?

Ты не должен :-) но вот в прошлый раз (Зачем нужны динамические языки) Miguel мою гипотезу понял, и продолжил разговор, а ты решил, что она вероятно тоже бред.

Я *очень* сжато выражаюсь. При этом иногда делаю ошибки :-)

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

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

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

>Так давай разберемся, в этом смысл общения

давай

>Я здесь тусуюсь чтобы заполнять пробелы своего понимания, ты наверно тоже

когда не троллю. но троллю я редко

>Это определение не годится. В таком случае любой вызов императивной функции -- это декларативный код.

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

чему это противоречит-то?

> чему это противоречит-то?

И. программа есть частный случай Д. программы, когда декларативная программа может императивно исполняться РОВНО 1 спобом, и в твоем определении нет хотя бы размытого разграничения между Д. программой, и И. программой.

>в твоем определении нет хотя бы размытого разграничения между Д. программой, и И. программой

если код описывает последовательность действий, он императивный. по-моему всё просто :) вот описание интерфейса в Java - вполне себе декларативное; реализация - императивная. если весь код программы декларативный - вся программа является декларативной. только толку от неё будет мало, разве что она написана на декларативном (и, возможно, не Тьюринг-полном) DSL

>> преобразовывал всё это к функциональной записи *только если это действительно надо*, а если не надо -- оставлял во вполне императивном виде

> вот этого мне в упор не понять. я понимаю, зачем может быть нужно наоборот, но не это.

Преобразование к функциональной записи например дает возможность совершать оптимизации скорости, распараллеливание, и другие интересные вещи типа STM.

Преобразование к императивной записи требуется при генерации машинного кода.

Вроде так.

> вот описание интерфейса в Java - вполне себе декларативное;

Это описание именно интерфейса, а не кода. Оно немного тут не по теме.

> вся программа является декларативной. только толку от неё будет мало, разве что она написана на декларативном (и, возможно, не Тьюринг-полном) DSL

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

>> Настоящая декларативность -- это когда результат трансформации декларативного кода в императивный код НЕОДНОЗНАЧЕН и скорее всего допускает нетривиальные оптимизации, выполнение которых "напрямую руками" затруднительно, нечитабельно, легко может привести к ошибкам

> как разрешать неоднозначность?

Как угодно, но можно в пользу большей скорости, меньшей памяти, ...

> делает ли добавление в язык средств разрешения неоднозначностей его менее декларативным?

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

> что такое "скорее всего"

четкую границу я затрудняюсь провести

> и где разница между "напрямую руками" и "с помощью макры", например?

если невозможно написать альтернативные макры, которые генерили бы совсем другой код -- то это не декларативный язык

> если весь код программы декларативный - вся программа является декларативной. только толку от неё будет мало, разве что она написана на декларативном (и, возможно, не Тьюринг-полном) DSL

Почти это я и сказал Macil-у раньше в этом треде.

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

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

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

>Это описание именно интерфейса, а не кода. Оно немного тут не по теме. Ну сами по себе описания классов - именно декларативные конструкции, другое дело что декларативность той же java где-то на этом и заканчивается.

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

Независимость_реализации_от_интерфейса обеспечивают все современные языки. Я отказываюсь ее считать полноценной декларативностью.

Полноценная декларативность -- это если бы компилятор языка автоматически генерил реализацию из интерфейса и ОБЯЗАТЕЛЬНО существовала бы альтернативная реализация, т.е. интерфейс не описывал последовательность императивных команд на 100%.

>Как угодно, но можно в пользу большей скорости, меньшей памяти, ...

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

>Такие средства полезны

при наличии неоднозначностей они необходимы. иначе толку от языка не будет никакого

>четкую границу я затрудняюсь провести

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

>если невозможно написать альтернативные макры, которые генерили бы совсем другой код -- то это не декларативный язык

вот этой фразы просто не понял. пояснишь?

>> Как угодно, но можно в пользу большей скорости, меньшей памяти, ...

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

берется Л_Ю_Б_О_Й вариант

мой пример с мейкфайлом в УЖЕ был этом треде, ладно напишу подробнее:

вход компилятора: мейкфайл в (идеализированном) функциональном формате + времена работы прошлых запусков команд

выхлоп компилятора: последовательность cтрок "wait X run_on Y command Z"

где

X=номер стоки, где запустился тот процесс, завершения которого ждать
Y=номер ядра процессора где пускать процесс
Z=сама команда с файлами-аргументам, без всяких там if/... и предназначенная не для шелла, а для ядра ОС.

s/стоки/строки выхлопа/

wait X в прниципе лишнее, но может с ним понятнее

>Все это голимая императивщина. Например, мы описываем класс на яве, с помощью рефлексии (и возможно учитывая аннотации) генерим к нему таблицы БД, методы для записи/чтения из БД, .

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

>Еще хуже с решением задачи линейного программирования -- тут вообще нет даже метапрограммирования

И очень зря. Ты пытаешься описать модель в терминах конкретного императивного языка (С, С++, Java) и начианется: твоя модель должна принимать определенные параметры в виде коэффициентов целевой функции и матрицы ограничений, проверять что все правильно, и пытаться _динамически_ решить задачу с помощью того или иного численного метода, т.е. на полную катушку используешь логические конструкции. Тебе все-равно в какой-то степени допускать декларативные определения, например в виде параметров.

А теперь представь, мы описываем нашу модель в каких-то терминах, не обязательно даже использовать DSL. После чего заполняем параметры модели и генерим _статическое_ решение, например с помощью LLVM.

Плюшек с такого подхода масса. И повышение производительности не главная из них. Приведу простой пример: обычно задачи линейного прораммирования решаются в канонической форме т.е. когда в качестве ограничений у тебя система линейных уравнений. Но на практике, задачу ЛП проще ставить в стандартной форме, когда у тебя в качестве ограничений система неравенств.

Преобразование, конечно тривиальное, но если модель опредеделена в терминах какого-то языка программирования общего назначения, у тебя могут быть большие проблемы, вплоть до переписывания заново. Зато, если моделть определена в каких-то "наших" терминах, то сдлеать преобразование из стандартной в каноническую форму намного проще.

>Настоящая декларативность -- это когда результат ее трансформации в императивный код НЕОДНОЗНАЧЕН

Настоящая декларативность, когда что-то _вычисляется_, а не _исполняется_.

>Хаскель мешает эти 2 *совершенно разные* вещи в одну кучу. Тут можно возразить...

Хаскель он много чего в кучу мешает. И к сожалению, на данном этапе развития, его слишком сложно использовать в настоящих приложениях. Лично все что мне удавалось - создать прототип сортировщика файлов по наборам правил на eDSL (комбинаторных).

> И очень зря

Вообще-то я не понял, зачем тут метапрограммирование, но верю без доказетельства, что оно очень нужно и очень полезно. И что в современных языках его не хватает. Насчет лиспа -- его метапрограммирование относительно неплохо, но лисповские s-exp как объекты poor man's algebraic data types вряд ли привлекут человека, знающего хаскель.

В общем, интересно было бы узнать что тебе хотелось бы видеть из метапрограммирования. Хотя бы на примерах.