mdw>Disclaimer: догадываюсь, что это я чего-то не понимаю . Очень хотелось бы понять в чем фокус. То есть что в lazy calculus такого, что делает его возможным в ФЯ, и трудно воплотимым в ИЯ.

Не трудно воплотимым, а опасным.

Ленивые вычисления (lazy evaluation) состоят в следующем.
В обычном (строгом) языке все аргументы функции f( x1, ..., xN ) вычисляются до вызова f.
При ленивом вызове все наоборот. Аргументы не вычисляются, пока не будут фактически использованы.
Это означает произвольный порядок вычисления аргументов, причем он может отличаться от вызова к вызову.
Функции-аргументы тоже могут быть ленивыми. Отсюда следует, что порядок вычислений в ленивом языке вообще не является фиксированным и заранее не определен.

Конструкторы типов тоже являются ленивыми функциями, что позволяет работать с бесконечными и рекурсивно определенными данными (не типами! А именно данными). Вот многострадальные числа Фибонначи:

fib             = 1 : 1 : [ a+b | (a,b) <- zip fib (tail fib) ]

Здесь определяется список чисел Фибонначи, ссылаясь сам на себя.
tail list — список без первого элемента
zip list1 list2 — преобразует пару списков в список пар значений.

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

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

Здравствуйте, Gaperton, Вы писали:
G>Это означает, что язык должен предоставлять соответствующий "синтаксический сахар", чтобы было удобно обходиться без модифицирующих операций. Такой язык будет являеться "функциональным".
Ну кстати плюсы содержат модификатор const, который при должном уважении к нему позволяет четко провести границу между модифицирующими и консервативными операциями. Теоретически, мы могли бы построить компилятор, применяющий ленивые техники там, где возможно, и работающий императивно в остальных случаях.

Хотспоттящий компилер мог бы идентифицировать лидеров консервативных вызовоа для обеспечения кэширования.
Многострадальные числа фибоначчи в твоем примере съедят всю доступную память при банальном поиске элемента, большего некоторой константы. Тупые некэширующие итераторы .Net победят благодаря отсутствию кэшировния, но продуют как только алгоритм потребует хотя бы второго прохода по той же последовательности. Ясно, что решение о кэшировании лучше принимать с учетом предполагаемого использования, а не встраивать в язык.

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

S>Многострадальные числа фибоначчи в твоем примере съедят всю доступную память при банальном поиске элемента, большего некоторой константы.

С чего бы?
Результат функции f(x1,x2,...) хранится в памяти до тех пор, пока он кому-то нужен. Если алгоритм поиска линейно перебирает числа фибоначи, то в памяти будет храниться только два числа.
PS: я про haskell

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

N_>С чего бы?
N_>Результат функции f(x1,x2,...) хранится в памяти до тех пор, пока он кому-то нужен. Если алгоритм поиска линейно перебирает числа фибоначи, то в памяти будет храниться только два числа.
N_>PS: я про haskell
Ну, это я от невежества. Я правильно понимаю, что речь идет о сборке мусора?

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

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

N_>>С чего бы?
N_>>Результат функции f(x1,x2,...) хранится в памяти до тех пор, пока он кому-то нужен. Если алгоритм поиска линейно перебирает числа фибоначи, то в памяти будет храниться только два числа.
Все так.

S>Я правильно понимаю, что речь идет о сборке мусора?
Абсолютно . Стоит отметить, что сборщики мусора с "поколениями" работают эффективнее при отсутствии модифицирующих операций.

S>Ну, это я от невежества. Я правильно понимаю, что речь идет о сборке мусора?

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

PS: В современных оптимизирующих компиляторах Си, Си++ и Фортрана программа преобразуется в промежуточную форму. Обычно это SSA форма (Single Static Assignment). А SSA в свою очередь эквивалентна функциональной программе.
http://citeseer.ist.psu.edu/appel98ssa.html

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

S>Здравствуйте, Gaperton, Вы писали:
G>>Это означает, что язык должен предоставлять соответствующий "синтаксический сахар", чтобы было удобно обходиться без модифицирующих операций. Такой язык будет являеться "функциональным".
S>Ну кстати плюсы содержат модификатор const, который при должном уважении к нему позволяет четко провести границу между модифицирующими и консервативными операциями. Теоретически, мы могли бы построить компилятор, применяющий ленивые техники там, где возможно, и работающий императивно в остальных случаях.
Будет ли это удобно, вот в чем вопрос. Nemerle, ссылку на который я тебе посылал, это шарпы, с добавленым функциональным синтаксическим сахаром. Вот это — один из практичных вариантов. Только там нет ленивых вычислений. Думаю, их можно добавить. По крайней мере, ленивые списки.

S>Хотспоттящий компилер мог бы идентифицировать лидеров консервативных вызовоа для обеспечения кэширования.
S>Многострадальные числа фибоначчи в твоем примере съедят всю доступную память при банальном поиске элемента, большего некоторой константы. Тупые некэширующие итераторы .Net победят благодаря отсутствию кэшировния, но продуют как только алгоритм потребует хотя бы второго прохода по той же последовательности. Ясно, что решение о кэшировании лучше принимать с учетом предполагаемого использования, а не встраивать в язык.
Боже упаси, кто тебя заставляет кэшировать? В конце концов, можно и как-нибудь так:

fib_create = (1, 0)
fib_number (current, _) = current
fib_next (current, prev) = (current + prev, current)

А хочешь — можешь определить класс типов (ADT) для числовых последовательностей, и сделать его реализацию для Фибонначи. Свобода, понимаешь. Как хочешь, так и делай.

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


S>>Ну, это я от невежества. Я правильно понимаю, что речь идет о сборке мусора?

N_>Нет. В хаскеле это делается во время компиляции.
N_>Когда вы пишите программу на функциональном языке, то описываете не последовательность действий, а то, как пеередаются и обрабатываются ваши данные. Компилятор строит граф потока данных и по нему генерирует код.
N_>Сборка мусора подключается только тогда, когда компилятор не может разобраться с временем жизни "объекта".
Прикольно. Так работают все G-машины, или это зависит от реализации? Пришлешь ссылки?

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

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

Кстати, о "чистых" функциях, я вдруг вспомнил...
В Фортране'95 они тоже есть! Так модификатор и назвали PURE.

real pure function toReal( x)
    real*4, intent(IN) :: x

    toReal = REAL( x)
end function

А вот какие от них радости:

A pure procedure can be used in contexts where other procedures are restricted; for example:

It can be called directly in a FORALL statement or be used in the mask expression of a FORALL statement.

It can be called from a pure procedure. Pure procedures can only call other pure procedures.

It can be passed as an actual argument to a pure procedure. (вот вам и функции высших порядков )

Кроме того, AFAIR, эти pure-функции являются ещё и intrinsic, то есть их можно вызывать при инициализации констант и значение будет вычислено уже на этапе компиляции

А ещё, есть такая разновидность pure-функций, как ELEMENTAL. Им, в качестве аргумента, можно подавать как простые числа, так и массивы, а они уж вернут результирующий обработанный массив, причем, насколько я вкурил, это всё будет выполне без создания копии вектора. То есть, компилятор сам постарается отложить фактическое выделение памяти под объекты до того момента, когда без этого уже никуда. Как ни крути, а похоже это они самые и есть — lazy evaluationы!
То же самое и с оператором FORALL, который специально заточен под эти самые pure-функции — там тоже что-то такое ленивое было, теперь уж и не вспомню...

Так-то вот. Пожалуй пора и Фортран зачислять в функциональные языки...

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

VD>>Хаскель это встоено как поганая надстройка

Q>С чего это ты это взял?

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

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

VD>>А тебе не странно что на том же ОКамле тоже есть побочные эффекты?

Q>Ничего странного в этом нет. Они по-любому должны быть, поскольку иначе невозможно общаться с внешним миром. Для того, чтобы этой возможностью не злоупотребляли, было сделано так, чтобы императивно программировать на OCaml было неудобно.

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

Q>Реально, императивные места встречаются редко и их легко отследить.

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

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

INT>К сожалению, в OCaml даже слишком много императивщины. В том числе и в библиотеках.

Это жизнь. Небыло бы там "императивщины", небыл бы Окамл сравнимым по проивзодительности с ИЯ.

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

G>Не думал, что у вас создание такого класса представляет такую сложность . А у нас — вот так:
G>

G>fib             = 1 : 1 : [ a+b | (a,b) <- zip fib (tail fib) ]
G>

G>Напиши такое на шарпе, можешь даже воспользоваться yield. Посмотрим, позволяет-ли он определать рекурсивные типы данных. Да, кстати, насчет "не думал" — это я слукавил. Я весьма хорошо представляю себе, как это будет выглядеть (правда, без yield)

Для меня этот пример не более чем набор "палочек". Опиши что хочешь получить словами.

Что же касается рекурсивных типов данных, то ты опсываешь функцию, а не данные. Данные могут ссылаться на себя, но не могут быть сами пос себе рекурсивными. Чудес не бывает.

G>Ответ неправильный.

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

G> Иногда необходимо кэшировать предыдущие.

Кто-то запрещает?

G> Этот пример вычисляет фибонначи эффективно — сложность O(N),

Да плевать всем на фиборачи. В мирной жизни такая лабуда не встречается. Если ФЯ для математиков, то дальше разговаривать нечего. У них и у всех остальных задачи кардинально разные.

G> как раз благодаря кэшированию серии элементов (которое происходит абсолютно прозрачно). Синклеру приводил пример, когда кэшировать надо вообще все: http://www.rsdn.ru/Forum/Message.aspx?mid=790607&only=1

Автор: Gaperton
Дата: 02.09.04

.

Блин. Если надо, то значит надо. Или в ФЯ все святым духом делается?

Ты утверждаешь, что на ФЯ нельзя создать линивых вычислений. Вот тебе пример примитивного варианта:

class A
{
    int _value = 0;
    public void Next() { ++_value; }
    public int Current() { return _value; }
}

...

A a = new A();
for (;;a.Next())
{
    ... a.Current() ...
}

Что это по твоему не линивые вычисления? Нужно обязательно создать список из всех допустимых значений?

Ну, раз линивые, то закроем этот спор. Признай что сморозил глупость.

G>Возможно. На самом деле "ленивые потоки" — наименее опасный вид ленивых вычислений. Это вполне можно включить в императивный язык, как синтаксический сахар и приятную мульку. Но и только.

А только и нужно. Все остальное для теоритиков.

G>Потому как насчет устранения необходимости кэширования — это еще бабка надвое сказала.

Да пускай она все что хочешь говрир. Ты за ней не повторяй.

G> К барьеру. Напиши код на С#, который имеет такую же характеристику, как приведенный код для фибонначи. А мы посмотрим, где проще ошибиться. Обрати внимание, что если я напишу
G>

G>process1( fib ) + process2( fib ) + process3( fib )
G>

G>то числа фибонначи все равно вычисляются один раз, а не три.

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

Проблема ФЯ в том, что для жизни на них очень тяжело задачу найти. Библиотеки все черт знает для чего предназначены. Сравнить с тем же фрймворком ну, никак не получается. Давно вот говорю перепишите тесты из шустриков. Хоть что-то можно будет сопоставить. К примеру, вот крайне выгодный для ФЯ тест рассчета ПИ:

public static string pi(int digits)
{
    if (digits > 54900)
        throw new System.Exception("n must be <= 54900");
    
    StringBuilder pi = new RStringBuilder(digits);
    string[] zero = { "0", "00", "000" };
    int d = 0, e, b, g, r;
    int c = (digits / 4 + 1) * 14;
    int[] a = new int[c];
    int f = 10000;

    for(int i = 0; i < a.Length; i++)
        a[i] = 20000000;

    while((b = c -= 14) > 0)
    {
        d = e = d % f;

        while(--b > 0)
        {
            d = d * b + a[b];
            g = (b << 1) - 1;
            a[b] = (d % g) * f;
            d /= g;
        }

        r = e + d / f;

        if (r < 1000)
            pi.Append(zero[r > 99 ? 0 : r > 9 ? 1 : 2]);
        pi.Append(r.ToString());
    }
    return pi.ToString();
}

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

G>Конечно я не хочу в это поверить. Это не религия, а инженерное жело. У нас в предыдущем проекте вся подсистема обработки данных на С++ имеет ленивую семантику (обсчитывается то, что видно на экране, и потом кэшироется, и так в несколько слоев),

Ну, а зачем тогда глупости утверждать?

G> и я за последние 6 лет имел возможность каждый день видеть, какой ценой это делается на ИЯ.

А может у вас все же не в бобине проблемы были? Да и С++ сам по себе проблем создает выше крыши. Я вот на С++ тоже много проблем имел. А на Шарпе как-то не очень. Все больше алгоритмические и проетные. И при изменениях ничего не разваливается.

VD>>Поверь итераторы не менее ленивы чем Хаскель.
G>Я последние 10 лет писал на ИЯ, и имею возможность сравнить сам. И вообще, зачем мне верить тебе на слово? Приведи пример, как подобает серьезным людям.

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

G>Ясно конечно, за кого ты меня принимаешь?

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

G> А тебе неужели не ясно, что "можно" и "целесообразно" разные вещи?

Можно цитатут где бы ты говорил о целесообразности? Ты тут утверждал о невозможности. Вот теперь идешь на попятные. Про целесообразность вспомнил вот...

G> На ассемблере можно сделать все, что угодно. Следует ли из этого, что на нем надо писать бухгалтерские программы?

Нет конечно. Это прерогатива ФЯ.

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

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

И естествнно даже не задумался, над тем что нужно было более тщательно все спроектировать... Переписал все на ФЯ и все само сабой заработала. Причем быстрее белее и пушистее...

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

X>Безотносительно к теме спора, конкретно вот это высказывание напоминает споры C/С++/Pascal vs assembler несколько лет назад — "на ассемблере и макросах можно сделать все то же, что и на С++, даже лучше"

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

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

G>Дорогой Влад, последние 6 лет я в составе команды человек в 20 занимался разработкой и поддержкой клиент серверного приложения объемом ~60 мегабайт кода (это 3-5 миллионов строк, не считая комментариев и пустых) написанного на С++, из которых 18 — моя зона ответственности. И это не какой-нибудь простой препроцессор, а сервер своей базы данных, интерпретатор всроенного языка, обработка потока котировок в реальном времени, и еще куча всего.

Рад за тебя. Вот только кроме тебя были и другие люди пишущие код. И у некоторых из них он таки работал.

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

Ну, прям обучение неумелого щенка не тыкаться носом в стену. Поверь участвал я в более менее больших проектах. Не 60 мег но все же. И проблемы видел. То что ты все время говоришь о плюсах и о своем неудачном опитые всего лишь говорит о том, что твои скилы на плюсах меньше чем нужно чтобы решить данную проблему. Собственно я даже не спорю, что писать большие проекты на С++ задача не простая. И что С++ вообще не самый лучший язык с точки зрения простоты и отладки. Но на плюсах свет клином не сошелся. Есть и дуругие языки у которых нет такого вороха проблем и такой сложности. Ты все время давишь на сложность отладки. А я за последние годы за отладкой больше двух часов к ряду (над одной проблемой) не сидел. Причем если засиживался дольше минуты, то это были сложные зависимости в алгоритмах. Сложность заключалась в том, чтобы понять ситуацию. А вот с побочными эффектами и прочей лабудой о которой ты все время толдычешь пролем нет! Дольше 5 митут на отладку подобных проблем у меня не уходит. Так что оставь эти песни для других.

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

VD>>И сколько ты их собрал за свою жизнь?
G>Штук 20, начиная от самых простых (маленький магазин), до достаточно сложных (магазин с полным набором торгового оборудования, оптовая торговля, производство). Примеры — Stentor, фабрика спортивных изделий Leco, издательский дом IST. Занимался этим три года, с 1997 по 1999. Еще вопросы?

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

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

VD>>Так не трепался бы.
G>Я и не треплюсь. В отличие от некоторых, я веду предметные разговоры.

Я плякль...

G>Если пропасть состоит в том, что мэйнстрим-программистов интересует только то, что использует МС — то ее не увеличишь и не уменьшишь разговорами. И с такими людьми, которые не слушая аргументов долдонят одно и тоже, мне разговаривать не интересно, пусть думают что хотят.

Значит не понял. Ну, тут ничего не поделашь.

ЗЫ

Кстати, об МС. Они спонсируют разработку в МСРесерче аж трех ФЯ (#F — Окамл для дотнета, SML.NET и GHC). И видимо когда вся эта лабуда созреет, возмут ее на вооружение, или возмут из нее правильные идеи и добавят в тот же Шарп. МС из тех кто хорошо воплощает в жизнь правильные (чужие) идеи. Так что то что они не используют ФЯ как раз хорошее доказательство их сырости. Идеи джита и промежуточного языка были придуманы в 70-ые. Но только сегодня Сан и МС воплощают их в жизнь на высоком техническом уровне. Думаю, что с идеями ФЯ, вроде функций высшего порядка и паттерн-матчингом будет тоже самое. Просто всему свое время.

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

VD>>Да потому что ты понятие не имешь что такое экономика. А он как раз говорил тут о ФЯ не как о языках программирования, а как о товаре и инструменте на ранке.
G>Ах, так это была тонкая экономическая аналитика? Ну тогда оставляю вас и дальше рассуждать об "экономике". Напоминаю, может кто забыл — я веду беседу о ФЯ.

Это была демонстрация твоего подхода к спору. Но ты даже не узнал себя в зеркале.

VD>>И вы показали полное незнание в данном вопросе и так и не дали внятного и разумного ответа на его вопрос. Причем лично мне совершенно ясно почему. Потому что ответ вам не выгоден.
G>То что тебе всегда все ясно, ни для кого не секрет. Завидую, жить легко наверно.

Ну, советовать смотреть в зеркало снова будет как-то банально.
В обещм, не стоит переводить стрелки...

G>А ответ на этот вопрос давался трижды немного выше по ветке. Вы его игнорируете, потому что ответ вам не выгоден.

Ответа небыло. Была разведена трехэтажная демагогия с оскорблениями. Мол ты пацан вообще молчи. Ты в вопрсе не шариш и нефига на МС пенять.

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