Зачем нужны динамические языки?

> А мужики то в ITA Software, Franz и много других и не знают. Ouch. Засунь свое мнение куда подальше.

Вполне возможно, что люди вашего круга общения впадают в автоматический экстаз, заслышав слова "ITA Software, Franz".

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

> по сравнению с нутром boost.lambda - сказка. или ты с чем-то другим предлагаешь сравнить? с boost.mpl, например? с felix?

boost.lambda делает то, что вы никоим образом не делаете -- дает возможность прозрачно подключить через указатели много чего есть на с++.

Полноценную реализацию функционального программирования на с++ (такой однако нет) можно было бы сравнивать только c реализацией хаскеля, который умел бы безопасно дергать с/с++ функции БЕЗ ffi.

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

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

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

> и никакого метапрограммирования

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

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

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

Я все же сегодня сделаю наборосок.

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

Однако создавать иллюзию и ограничивать средства можно существенно по-разному (в зависимости от специфики задачи и от подхода), откуда и вылезают разные функциональщины.

> А если для программистов, почему не поставлять компилятор в отдельном пакете, или еще лучше, пользоваться общесистемным?

Ну да, вполне разумно.

> 1. А по-моему разной процедурщины вообще не бывает. Она одна, в отличие от функциональщины.

> 2. И в чем это проще? Развей тему.

a) Собственно, уже сделано. Я понимаю, что уже задолбал слегка, но всё-таки: монады. Каждая монада даёт тебе свою разновидность императивного кода. Какая-то - даёт тебе эквивалент C (IO), какая-то - доступ к одной (и только одной) переменной (State), и т.п.

б) Помимо того, что писать на том, что уже есть, проще, чем на том, чего нет - функциональщина вообще обычно проще.

> реализацией хаскеля, который умел бы безопасно дергать с/с++ функции БЕЗ ffi.

Код на Хаскеле:

-- Example: Computing some Fibonacci numbers: fib = do { a <- arrayU[40]; i <- auto 0; a[0] =: 1; a[1] =: 1; for (i =: 2, (i :: EIO Int) < 40, i += 1) $ do { a[i] =: a[i-1] + a[i-2]; }; retrn (a[39]); }

-- Example: Copying stdin to stdout: cat = do { c <- auto 0;

while ((c =: getchar()) >= 0) $ do { putchar(c); }; return (); }

Блин, форматирование:

> реализацией хаскеля, который умел бы безопасно дергать с/с++ функции БЕЗ ffi.

Код на Хаскеле:
-- Example: Computing some Fibonacci numbers:
fib = do {
a <- arrayU[40];
i <- auto 0;
a[0] =: 1;
a[1] =: 1;
for (i =: 2, (i :: EIO Int) < 40, i += 1) $ do {
a[i] =: a[i-1] + a[i-2];
};
retrn (a[39]);
}
-- Example: Copying stdin to stdout:
cat = do {
c <- auto 0;
while ((c =: getchar()) >= 0) $ do {
putchar(c);
};
return ();
}

> какая-то - доступ к одной (и только одной) переменной (State)

А если мне надо несколько переменных с указателем, ссылающимся на одну из них?

_________________________________

Теперь насчет функциональщины поверх процедурщины -- простейший способ -- это сделать как в D атрибут pure для функций. Какие будут претензии к этому способу?

> Блин, форматирование:

не мучайся, я совсем не это имел в виду

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

половинчатый ответ (разные функциональщины): вот в D компилятор тупо проверяет атрибут pure, а ведь могут быть случаи, когда компилятор этот атрибут отвергает, а ты можешь доказать, что зря он это делает, с учетом специфики задачи. Если эти доказательства обобщить слегка и поставить на поток -- получим другую функциональщину.

> А если мне надо несколько переменных с указателем, ссылающимся на одну из них?

Переменная может быть любого типа, так что любая структура данных подойдёт.

> вот в D компилятор тупо проверяет атрибут pure, а ведь могут быть случаи, когда компилятор этот атрибут отвергает, а ты можешь доказать, что зря он это делает, с учетом специфики задачи. Если эти доказательства обобщить слегка и поставить на поток -- получим другую функциональщину.

Угу, это делает монада ST. В ней ты можешь писать императивный код, который на выходе станет чистым. Всё, что тебе нужно - это не позволить сайд-эффектам "вылезти наружу"; система типов за этим проследит автоматически.

> не мучайся, я совсем не это имел в виду

Ещё один хаскельный пример (честно, это действительно хаскель):

main = runBASIC $ do
    10 GOSUB 1000
    20 PRINT "* Welcome to HiLo *"
    30 GOSUB 1000

    100 LET I := INT(100 * RND(0))
    200 PRINT "Guess my number:"
    210 INPUT X
    220 LET S := SGN(I-X)
    230 IF S <> 0 THEN 300

    240 FOR X := 1 TO 5
    250   PRINT X*X;" You won!"
    260 NEXT X
    270 STOP

    300 IF S <> 1 THEN 400
    310 PRINT "Your guess ";X;" is too low."
    320 GOTO 200

    400 PRINT "Your guess ";X;" is too high."
    410 GOTO 200

    1000 PRINT "*******************"
    1010 RETURN

    9999 END

>boost.lambda делает то, что вы никоим образом не делаете -- дает возможность прозрачно подключить через указатели много чего есть на с++

а ещё boost.lambda не позволяет использовать в своих выражениях оператор точку ('.'), потому как его нельзя перегружать - и не заставишь ты его возвращать прокси хоть тресни. не позволяет делать локальные объявления. не поддерживает вложенные лямбды. ну очень прозрачная и удобная библиотека

а главное патчить её - сплошное удовольствие, код Яакко Ярви понятен даже ребёнку, не так ли?

>Полноценную реализацию функционального программирования на с++ (такой однако нет)

не удивительно

>можно было бы сравнивать только c реализацией хаскеля, который умел бы безопасно дергать с/с++ функции БЕЗ ffi

как можно безопасно дёргать грязные функции без FFI?

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

в условиях наличия в GHC квазиквотации - одно и то же. транслятор этого языка в хаскель используется в компайл-тайм. тебе дать ссылки на eDSL-реализации nesC и IA-32 в Haskell?

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

угу, потому что в большинстве случаев проще удавиться. или написать на чистом C и не сношать себе мозг

>Вроде макры нагляднее

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

>Грубо говоря внешний мир программы процедурен

внешний мир программы - это машина Тьюринга и фон-Неймановская архитектура. к процедурному программированию (фреймам) прямого отношения не имеет

>хотя вы тут можете спорить

с удовольствием причём

>Функциональщина -- это такой хитрый способ создать иллюзию, что мир неизменен

у тебя очень однобокий взгляд на функциональщину; иммутабельные данные и в Java сделать можно, и что - Java внезапно станет ФП-языком?

>или ограничить средства написания проги так

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

>Однако создавать иллюзию и ограничивать средства можно существенно по-разному

почему ты упорно считаешь что ФП - это кастрированная императивщина? это, мягко выражаясь, не так

>Теперь насчет функциональщины поверх процедурщины -- простейший способ -- это сделать как в D атрибут pure для функций. Какие будут претензии к этому способу?

это никоим местом к функциональщине не относится. пойдёт такая претензия?

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

Меня пока что интересует:

1. Тот пример на хаскеле, который sf так и не привел

2. Сравнение сложности реализации "функциональщина на процедурщине" (ФнП) и наоборот (ПнФ). Под реализацией понимается НЕ компилятор, а реализация строго внутри языка. Речь может идти

ПнФ: это например как на хаскеле через монады

ФнП: это например слово pure как в D c тупой проверкой его компилятором -- здесь меня как раз больше всего интересует ваша критика.

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

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

Никуда вы не сдвинулись, я не лиспер! Это они преподносят макры как киллер фичу. Я же сказал что я думаю.

> это никоим местом к функциональщине не относится. пойдёт такая претензия?

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

> а ещё boost.lambda не позволяет

Это ты ее зачем-то приплел. А теперь критикуешь (хотя и полность справедливо).

>1. Тот пример на хаскеле, который sf так и не привел

можно повторить постановку задачи? тут уже так нафлудили, что шиш найдёшь :(

>2. Сравнение сложности реализации "функциональщина на процедурщине" (ФнП) и наоборот (ПнФ). Под реализацией понимается НЕ компилятор, а реализация строго внутри языка. Речь может идти

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

>ФнП: это например слово pure как в D c тупой проверкой его компилятором -- здесь меня как раз больше всего интересует ваша критика

это ни разу не функциональщина

можно на D в локальную переменную сохранить функцию, созданную на лету как композицию двух-трёх других функций? let f = a . b . c in ...? можно на C++ реализовать вложенные лямбды? замыкания? новую синтаксическую конструкцию (for else из Python'а, например)?

>Почему тогда подмножество этого языка будет не функциональным языком?

хотя бы потому, что в нём будет фиксированный порядок вычислений. вместо редукции - последовательное выполнение комманд

> тебе тезис Чёрча-Тьюринга о чём-нибудь говорит

А ты читал хотя бы мои посты в этой ветке, и хотя бы тот пример с регулярными выражениями -- речь шла не о вычислимости вообще, а о экспоненциальном/линейном времени.

>Это ты ее зачем-то приплел

это пример попытки реализовать кусочек ФП в императивном языке. со всеми вытекающими ограничениями. я ещё на boost.mpl предлагал посмотреть, там тоже весело. и на felix

>> Почему тогда подмножество этого языка будет не функциональным языком?

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

Почему фиксированный порядок делает субъязык ВДРУГ нефункциональным? Ведь у нас в субъязыке все функции чистые.

>> Это ты ее зачем-то приплел

> это пример попытки реализовать кусочек ФП в императивном языке. со всеми вытекающими ограничениями.

НЕПРАВИЛЬНО. это пример реализовать ФП в языке с бедной системой типов и низкими возможностями метапрограммирования, со всеми вытекающими ограничениями.

императивность тут никоим боком.

>А ты читал хотя бы мои посты в этой ветке

не все

>пример с регулярными выражениями

опять же, можно повторить? буду весьма признателен

>экспоненциальном/линейном времени

оптимизация есть везде, и в ФП тоже. наивный парсер CF-грамматики в ФП имеет экспоненциальную сложность по времени, мемоизация уменьшает её до кубической, частичные вычисления - до квадратичной. последняя на сегодня версия regex-tdfa для Haskell имеет линейную сложность по времени

>Почему фиксированный порядок делает субъязык ВДРУГ нефункциональным? Ведь у нас в субъязыке все функции чистые

потому что чистота - это не единственный критерий функциональности языка. это вообще не критерий. язык может быть функциональным и не быть при этом чистым (см. Caml)

> можно на D в локальную переменную сохранить функцию, созданную на лету как композицию двух-трёх других функций? let f = a . b . c in ...? можно на C++ реализовать вложенные лямбды? замыкания? новую синтаксическую конструкцию (for else из Python'а, например)?

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

Допустим, что у нас есть с++ со словом pure проверяемы компилятором, возможностью на ходу делать (в т.ч. вложенные) замыкания, ленивыми параметрами функций (что в общем те же замыкания) и некоторой (чуть посильнее чем щас) системой типов.

И чем субъязык из чистых функций будет не функциональным языком?

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

короче, выдай свой критерий.

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

неправильно тебе кажется. про композицию ответишь что-нибудь? про синтаксическую (семантическую, вообще говоря) конструкцию? в ФП это делается элементарно

> можно повторить постановку задачи? тут уже так нафлудили, что шиш найдёшь

http://www.linux.org.ru/jump-message.jsp?msgid=3594542&cid=3600072

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

> неправильно тебе кажется. про композицию ответишь что-нибудь? про синтаксическую (семантическую, вообще говоря) конструкцию? в ФП это делается элементарно

А по-моему ты лишнего тратишь свою энергию на стрельбу по площадям. Давай разберемся с самого начала -- с критериями ФП.

>короче, выдай свой критерий

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

>А по-моему ты лишнего тратишь свою энергию на стрельбу по площадям

а ты всё время отвечаешь на один и тот же вопрос, весело игнорируя все остальные. и что?

Причем я спрашиваю твое личное мнение, которое может отличаться от википедии.

In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data.

Соответственно я и справшивал, и спрашиваю -- если я сделаю подъязык императивного языка (я уже писал) -- то чем этот подъязык будет не функциональный?

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

Далее я формулирую типа теоремы: если в имеративный язык добавить по мелочам pure/closure/... то он поимеет подможнество, изоморфное функциональному языку, причем изоморфное достаточно прямо (а не криво).

Это я и хочу обсудить. Для начала.

>treats computation as the evaluation of mathematical functions

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

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.27.7800

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.14.8661

>Причем я спрашиваю твое личное мнение, которое может отличаться от википедии

да ты хоть бы уже википедию читал внимательно

>Далее я формулирую типа теоремы: если в имеративный язык добавить по мелочам pure/closure/... то он поимеет подможнество, изоморфное функциональному языку, причем изоморфное достаточно прямо (а не криво)

ну докажи. докажешь - приходи :)

>Это я и хочу обсудить. Для начала.

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

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

Правда, "императивное наследие", скорее всего, помешает тебе навесить многие другие фишки, полезные, но для "звания функционального языка" необязательные - что, увы, скажется на результатах, которые ты в результате получишь. Скажем, ту же Software Transactional Memory реализовать полностью на нечистом языке... не представляю, как. Возможно, DDC справился бы с этим, но чтобы кто-нибудь ещё - вряд ли. Но, в принципе - да, подмножество, изоморфное (в некотором смысле) функциональному языку у тебя будет.

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

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

Ну тогда остается только тема с тем примером, который на хаскеле не дали.

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

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

Пример: если бы оператор . в с++ имел бы еще и другую синтаксическую версию a.b <===> subfield(a,b) то проблем бы у буста с ним не было (?)

DDC = ?

>> ФнП: это например слово pure как в D c тупой проверкой его компилятором -- здесь меня как раз больше всего интересует ваша критика

> это ни разу не функциональщина

> можно на D в локальную переменную сохранить функцию, созданную на лету как композицию двух-трёх других функций? let f = a . b . c in ...?

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

> можно на C++ реализовать вложенные лямбды? замыкания?

Без доработки компилятора - нет.

> новую синтаксическую конструкцию (for else из Python'а, например)?

Нет. Но это в в любом не-ленивом языке нельзя сделать, будь он даже функциональный.

А почему именно такой (странный, ИМХО) список требований?

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

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

Так, например, если мы не можем заставить компилятор проверять "чистоту" функции (скажем, тот же атрибут pure), то Software Transactional Memory не реализуется вообще, либо является чрезмерно подверженной труднообнаружимым ошибкам. Если можем - то надо ли нам вообще то, что не pure, если интересные вещи (не только STM) требуют pure? Либо нам надо забить на интересные вещи из функциональных языков и делать другие интересные вещи, из, например, императивных языков - тогда, опять-таки, непонятно, зачем был этот pure.

DDC - диалект Хаскеля, умеющий сайд-эффекты и отражающий тип сайд-эффектов в типе (пардон за перегрузку термина "тип") самой функции. Скажем, тип функции map в нём таков, что из него очевидно: map f даёт только такие сайд-эффекты, которые даёт функция f, и никакие другие. Если f - чистая функция, то map f - тоже чистая.