CL

> их стоит считать атрибутами System F. всегда ваш, К.О.

А причем тут? :)

А причем тут?

гм? ну, перечисленное - это как раз System F. статическая типизация, вывод типов, классы типов

или вы о чём-то другом?

> ну, перечисленное - это как раз System F

Но речь-то шла о «ФП вообще», а System F - всего лишь один из механизмов реализации.

Кстати, из Вики:

Wells' result implies that type inference for System F is impossible.

Wells' result implies that type inference for System F is impossible.

што? а тайпчекер хацкеля как тогда работает?

>> Wells' result implies that type inference for System F is impossible.

што?

Да.

а тайпчекер хацкеля как тогда работает?

Коллективный самогипноз.

P.S. ты сам-то ходил по своей ссылке? :)

> што? а тайпчекер хацкеля как тогда работает?

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

ну тогда всё в порядке

> ага, а с учётом того, что объекты - это замыкания для бедных

раскрой тему подробнее — чем замыкания лучше объектов?

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

максимум что получится — это poor man's AlgDT

> Я придумал простую монаду для представления динамических процессов, интегрируемых методами Рунге-Кутта и Эйлера. Проблема в том, что такие процессы недетерменированы (стохаcтистические) по своей сути. Каждый новый прогон - новые результаты. Такая монада легко реализуется на F# и лиспе. На F# у меня уже есть готовый рабочий образец. Может быть, сделаю для лиспа. Но я совершенно не представляю, как это сделать в хаскеле. Нужна недетерменированность и непременно мемоизация внутри одного прогона (монады).

Cоздай тему и с проси, как это сделать на хаскеле. Мне тоже интересно сравнить это с с++.

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

пару? тебе маркетологом работать, лапшу на уши вешать

ты хотя бы можешь привести ссылку на статью «когда следует писать декларации типов, а когда нет» ?

> primes = 2:[x | x <- [3, 5..], not $ any ((== 0).(mod x)) $ takeWhile (<= floor (sqrt $ fromIntegral x)) primes] Порядок вычислений тут важен. Где нарушение функциональной парадигмы?

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

> По-моему, точного и полезного определения функционального программирования не существует.

Полезно бы его составить.

1. function as first class citizen — в си этого вообще нет, в с++ синтаксическое приближение к этому, а идеал — чтобы синтезированная в процессе вычислений функция могла подаваться всюду, где требуется допустим int (*f)(int) и не строить при этом трамплины, не исполнять стэк, и т.д.

я не знаю, можно ли это сделать в рамках стандарта вызовов си

2. все, что дает оптимизацию распараллеливания

3. все, что дает оптимизации вычислений, связанных с мемоизацией (типа алгоритма КМП)

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

3. все, что дает оптимизации вычислений, связанных с мемоизацией, основываваясь на том, что значение функции зависит только от аргументов (типа алгоритма КМП)

> ты хотя бы можешь привести ссылку на статью «когда следует писать декларации типов, а когда нет» ?

а точно не помню, в хаскелл кафе было когда-то обсуждение и еще где-то читал. А что-то не так?

> poor man's AlgDT

Почему poor? Тот же deftype мощнее adt. Правда adt имеет смысл только в статических языках, по большому счету.

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

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

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

это ты так думаешь. те, кто думает противоположное, придумали частичное применение

> это ты так думаешь. те, кто думает противоположное, придумали частичное применение

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

> А это не имеет к этому никакого отношения, пока ты не вычислишь все, ты все-равно не получишь конечный результат.

да, только в случае ФП порядок вычисления каждого елемента этого «всего» не важен. при любой форме записи

> да, только в случае ФП порядок вычисления каждого елемента этого «всего» не важен. при любой форме записи

а это и не утверждалось.

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

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

к чему тогда это было?

раскрой тему подробнее — чем замыкания лучше объектов?

ничем

http://community.livejournal.com/ru_lambda/27669.html

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

(map (lambda (x) (foo x)) '(1 3 4))

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

>> (map (lambda (x) (foo x)) '(1 3 4))

или так (map 'list (lambda (x) (foo x)) '(1 3 4)) или так (mapcar (lambda (x) (foo x)) '(1 3 4)) , но не так как у тебя :)

> (map (lambda (x) (foo x)) '(1 3 4))

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

>> А то что итоговое поведение системы зависит от неявных аргументов: *debuger-hook* и *break-on-singlas*. Только динамические переменные используются не только для ввода/вывода и обработки исключений, но вообще повсеместно, как в стандарте, так и в коде реализаций (каждая реализация добавляет своих), так и в пользовательском коде. Формы defparameter и defvar приводят к появлению динамических переменных. Любой вычислительный процесс в Common Lisp просто нашпигован неявными аргументами.

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

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

>> (map (lambda (x) (foo x)) '(1 3 4))

или так (map 'list (lambda (x) (foo x)) '(1 3 4)) или так (mapcar (lambda (x) (foo x)) '(1 3 4)) , но не так как у тебя :)

то он просто на Схеме пример привел, очевидно же... =)

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

казалось бы, при чем тут архимаг, к апологетам ФП никоим образом не относящийся?... =)

А тут кто-нибудь пробовал AllegroCache и/или AllegroGraph? меня эти штуки заинтересовали, но я ничего в них не понимаю и не знаю, стоит ли вообще пытаться понять.

>> казалось бы, при чем тут архимаг, к апологетам ФП никоим образом не относящийся?... =)

Просто он пал жертвой ФП пропаганды, часть которой повествует о том, что является признаками ФЯП. Аналогично ООП: ООП язык должен поддерживать наследование, которое к ООП имеет отношение постольку-поскольку. Также и ФЯП - должен поддерживать только ФЯП и только в чистом виде, все остальное не ФЯП.

>> А тут кто-нибудь пробовал AllegroCache и/или AllegroGraph? меня эти штуки заинтересовали, но я ничего в них не понимаю и не знаю, стоит ли вообще пытаться понять.

Если заинтересовали, то стоит :)

Ну это не замыкания, а анонимные функции

Это замыкание, но оно ничего не замыкает :) Хорошо, пусть будет так:

(let ((y 4)) (mapcar (lambda (x) (cons x y)) '(1 3 5)))

то он просто на Схеме пример привел

Нет, я просто ошибся. Обычно я в таких случаях пишу

(iter (:for x in '(1 3 4)) (:collect (foo x)))

Пользуясь случаем, рекомендую свою библиотечку iterate-keywords: пропатченный iterate, который позволяет обойти недостаток iterate - слишком большой список экспортируемых символов. В качестве «голов» предложений можно использовать одноименные keywords. Iterate, в свою очередь, если кто не знает - это правильная реализация циклов в лиспе (loop - это анти-лисповая реализация циклов).

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

А по хэштаблицам оно может?

У тебя очень выразительный ник. Сам придумал?

Может. По всему может, по файлам, потокам, векторам, пакетам. Например,

(let ((x (make-hash-table))) 
  (setf (gethash 1 x) 2) 
  (iter (:for (a b) :in-hashtable x) 
        (:collect `(,a ,b))))

Вот маркетинговая статья, http://common-lisp.net/project/iterate/doc/Don_0027t-Loop-Iterate.html#Don_00...

А вот мануал. http://common-lisp.net/project/iterate/doc/index.html

Может всё тоже, что и расширенный loop (+/- копейки), но с важными отличиями. 1. вместо уродливого «when x do ... and collect ...» можно пользоваться обычными управляющими конструкциями лиспа. 2. легко писать свои расширения (в loop это просто невозможно). Например, если есть функция mapquery, то легко сделать соответствющий синтаксис

(iter (:for (a b c) in-query «select a,b,c from table») (print b))

3. внутри iterate расширяются макросы, и это органично, т.к. синтаксис лисповый, а не коболовский.

Мой патч, соответственно, здесь iteratekeywords.sourceforge.net.

den73, а в чем суть пача?

Тонко. =))

Мммм... Да, нехорошо получилось.. :))