баг или фича

Что не отменяет того факта, что кроме обозначений он в лямбда-исчислении ничего не понял.

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

Нет.

Спасибо. Видимо это сакральное знание, недоступное простым смертным.

И уж точно к ООП имеет большее отношение, чем к ФП.

BTW, семантика хаскеля, на первый взгляд, весьма напоминает класс-ООП. Его типы, как 2 капли классы.

Нет. Но секретаршам таки да, недоступное.

Почему Вы не можете/хотите сформулировать основную идею ФП? Потому что считаете, что это невозможно сформулировать в краткой форме? Или из-за илитизма?

Потому, что осознание того, что ты понимаешь то, что не смог понять «основатель лиспа», добавляет 100500^100500 к ЧСВ ))

Я понимаю, что еще одним фетишем ФП является абстрагирование от порядка вычислений. В SICP есть пример с вычислением квадратных корней методом ньютона (аппроксимация), и это является одним из примеров построения API, когда мы в выражении (+ 1 (square 3)), абстрагируемся от того, что сначала нужно вычислить корень, а уже затем сложить. Там для этого применяется Ъ-функциональный стиль - подстановочная модель вычислений, и для этого не понадобились никакие неявные состояния, на которые дрочат хаскелисты. В принципе, этого можно добиться и императивными средствами.

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

Почему Вы не можете/хотите сформулировать основную идею ФП?

Не вижу смысла. Когда человек на голубом глазу говорит «Его типы, как 2 капли классы» и идёт на помойку за знаниями — тут нужен специалист другого профиля.

Ну так объясните для других, «способных», «подающих надежды». Я же не один читаю этот тред. А то у постороннего наблюдателя сложится впечатление, что не можете этого сделать. Я, во всяком случае еще ни разу не видел внятного объяснения. Очевидно, его просто нет.

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

Если Вы этого не понимаете, это не значит, что это не так.

Ну так объясните для других, «способных», «подающих надежды».

Зачем? Может, им не нужно?

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

Да плевать, что обо мне будет думать посторонний наблюдатель.

на помойку за знаниями

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

глазу говорит

И я могу предположить, по этому ответу, что Вы пришли в ФП именно из класс-ООП. Я прав?. Именно поэтому, для вас неочевидна эта «похожесть». Вам просто не с чем сравнивать. Вот если бы Вы были знакомы с прототипным ООП, связь эта была бы для Вас очевидна. А так, Вы за деревьями не видите леса.

Википедия это не помойка

Википедия в целом — нет. Русская википедия — в чистом виде помойка.

Русская википедия — в чистом виде помойка.

В таком случае на английской википедии определение по сути мало чем отличается. Оттранслируем в англо-версию:

a style of building the structure and elements of computer programs, that treats computation as the evaluation of mathematical functions and avoids state and mutable data. Functional programming emphasizes functions that produce results that depend only on their inputs and not on the program state

Причем вот это:

only on their inputs

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

Короче, если без демагогии, это дает нам только определенную степень безопасности целостности пространств имен. Мы точно также могли бы этого достичь условившись, например, употреблять в именованиях структур данных и функций которые к ним обращаются соответствующие префиксы, т.е. чисто синтаксически. Больше, ни в плане гибкости, ни в плане выразительности, (я уж не говорю о памяти, гы) тут преимуществ никаких нет. Скорей наоборот. Поэтому никаких причин делать из этого особую элитарную религию я не вижу.

Не вижу смысла. Когда человек на голубом глазу говорит «Его типы, как 2 капли классы»

Но классы типов в хаскеле сами по себе действительно ничем не отличаются от классоф с интерфейсами. Кроме синтаксиса, конечно. Более того - они специально так и сделаны, чтобы не отличаться.

Да, кстати, очень хотелось бы услышать Ваш коментарий

Хотел ответить раньше, но, по-моему, уже всё сказали.

Джон Маккарти придумал идею. Он сначала вообще не думал, что лишпик может быть языком программирования для машины. И реализовывал его не он. В той же History of Lisp написано, что просто так вышло, что Лисп получился динамическим, Маккарти и Рассел вполне понимали, что это нелогично и вообще баг. И даже его исправили потом.

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

Что касается самого слова «аномалия», то это просто ануслизинг такой эвфемизм. Ведь Бог-Творец Его Скобчатого Величества не мог ошибиться!

Бог-Творец Его Скобчатого Величества

со скобочками тоже смешно получилось. ведь Маккарти явно формулировал, что «у языка должно быть несколько синтаксисов, удобный человеко-читаемый и абстрактный синтаксис для машины, и возможно, другие по необходимости» (пруфлинк на цитату где-то в Readable Sweet Expressions).

в частности, для человекочитаемости предлагались M-выражения.

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

сиё есть странно — регулярно появляются более лучшие синтаксисы, например, наиболее проработанный — Sweet expressions, и ими всё равно не пользуются. а пользуются скобочками, плюются, и продолжают грызть кактус ... =)

Насколько я понимаю, если вводится подобный синтаксис, теряется code as data. Хотя сейчас это, может, не так актуально. В этом, видимо объяснение данного феномена.

а пользуются скобочками

Потому что ничего удобнее придумать так и не смогли. Как придумают - так все сразу и перейдут.

Лиспы долгое время были динамическими просто потому, что так легче писать интерпретаторы:

сюда же нечёткое разделение между фазами компиляции в CL, неясность в API стандартной библиотеки — что обязательное, что рекомендательное, как делать расширения и т.п.

становится понятнее, почему так получилось после прочтения «Common Lisp: the Untold Story», описывающей процесс стандартизации ОбщеЛиспа. вкратце, яйцеголовым ВНЕЗАПНО выделили гранты на исследования, и то, что они хакали для себя, на коленке ВНЕЗАПНО пришлось стандартизировать, и как-то за бабло отчитываться.

в итоге, стандартизация происходила в некоторой степени хаотически, не продуманно. два наиболее используемых диалекта, InterLisp и MacLisp до того применялись более-менее равноправно, после того — победил MacLisp, потому что он был в шаговой доступности у наиболее активной группы, а InterLisp как НЁХ пропал ибо ниасилели.

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

затем, кодифицировали в стандарте всю остальную глупость, которая до того может быть и имела смысл, но в новой системе (tm) её не мешало бы передумать и переделать.

в итоге, имеем стандарт в таком виде: если лозунгом С++ является «не платите за то, что не используете» — тут как раз наоборот, шведский стол.

стандарт можно и нужно было бы переделать. «ортогонализировать» фичи «генотипа и фенотипа лиспа»( (с) Марк Тарвер, Qi, Shen), выделив минималистичное ядро: строя язык как метаязык из «языковых модулей», концептуально ортогональных друг другу, изначально лучше интегрирующихся (на уровне метаязыка). затем, этот набор модулей бы регулярно пересматривался, на предмет, когда нужно какую-то новую фичу достаточно реализовать на базе имеющихся модулей, а когда нужно уже выделять в новый «языковой модуль».

например, те же языки Qi, Shen, kernel с тау-выражениями: «ортогонализировано» ядро языка в случае Qi -> Shen, минимум спец. форм и выражений в ядре; более другой способ реализации макросов через тау-выражения и fexprs в kernel.

Или, язык ISLISP в частности (стандарт ISO и JEC), и европейское семейство лиспов вообще, процесс стандартизации которых протекал более организованно, продуманно и рационально: тоже, в ISLISP минимизируется количество спец. форм, вместо функционально богатых, но сложных в реализации фич типа CLOS, AMOP и условий и перезапусков в стандарте предлагаются облегчённый C++-like ILOS, try-except-finally, чёткое разделение на время жизни переменных defglobal/defdynamic/defconstant (глобальные и динамические переменные, setq без такого объявления по стандарту ISLISP это ошибка), нормальная модульность require/provide и встраиваемость; что впрочем, не мешает реализовать остальное (и полноценный CLOS/MOP, и условия и перезапуски, и т.п.) — уже на базе этих более минимальных, ортогональных спец. форм (а не кодифицированной глупости всего стандарта CLtL2 целиком )

результат налицо: по «метрике Н. Вирта», если CLtL2 занимает примерно 1050 страниц, то стандарт ISO/IEC 13816:2007 Programming language ISLISP — всего 134 страницы.

Батарейки отдаются на откуп реализациям: но например, OpenLisp содержит кучу всего, в виде нормальных модулей.

Другое дело, что OpenSource реализаций, достаточно полноценных (как тот же OpenLisp) для ISLISP почти и нету.

А если взять языки Qi / Shen/ Shen 2 , то в Shen этот процесс «ортогонализации» и упрощения стандарта зашёл ещё дальше.

PS. Спасибо за перевод «Lisp in small pieces», отличная работа. Если ещё что соберешься переводить, есть предложение: попробуй Skribilo в S-выражениях и генерировать tex разметку им, а не писать tex разметку руками + какой-то XSLT для DocBook/epub/ODF для стилей. Есть мнение, что так будет технологичнее — выделить свои стили и писать только текст.

в том-то и дело, что в случае Readable Sweet expressions — не теряется. см. примеры. они и вводили-то свой синтаксис таким способом, чтобы все основные фичи типа гомоиконности, удобства написания макросов вроде `,' сохранились.

в отличие от множества самопальных infix синтаксисов.

Хотя сейчас это, может, не так актуально

ага, всем пофиг.

или, такая байка:

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

вот саундтрек

This is a film about a man and a fish
This is a film about dramatic relationship between man and fish
The man stands between life and death
The man thinks
The horse thinks
The sheep thinks
The cow thinks
The dog thinks
The fish doesn't think
The fish is mute, expressionless
The fish doesn't think because the fish knows everything
The fish knows everything.

радио изобрели, а всеобщего щастя так и не наступило =(

дзенская ылитне рыбка-лиспер же

The fish doesn't think because the fish knows everything
The fish knows everything.

в ISLISP минимизируется количество спец. форм

так глупо спалился

в том-то и дело, что в случае Readable Sweet expressions — не теряется.

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

мда, ошибка вышла. конкретно в ISLISP — не минимизируется: 40 спецформ в стандарте (пункт 12.3) против 25 в CL

отличия: новых 22 : and assure case case-using class cond convert dynamic dynamic-let for ignore-errors lambda or set-dynamic setf while with-error-output with-handler with-open-input-file with-open-output-file with-standard-input with-standard-output

меня смутила конкретно реализация OpenLisp: там тот же setf, while, ЕМНИП with-open-*-file не является спецформой, как по стандарту должен быть, а макросом, в отдельном модуле.

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

например, совместимость с CL сделана отдельным модулем с макросами clcompat (также, как совместимость с AutoLisp — другим модулем через макросы).

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

There might be additional, implementation-defined special operators.

в том же Shen это «минимальное подмножество» более минимально, и лучше «ортогонализировано»

я не вижу, что «сложность повышается на порядок». я вижу три синтаксиса (c-expressions,n-expressions,t-expressions), составленные из той же идеи гомоиконности, что и s-expressions. морфизмы, короче.

или приведи свой пример.

в крайнем случае, есть командно-строчные конверторы sweeten/unsweeten для конвертации туда-сюда.

см. примеры

в случае со схемкой с define-syntax так вообще всё просто (для CL пишут, возможно что-то недопилено пока ещё).

Original Lisp

(defmacro Square-Sum2 (X Y)
  (let ((First (gensym "FIRST-"))
        (Second (gensym "SECOND-"))
        (Sum (gensym "SUM-")))
    `(let* ((,First ,X)
            (,Second ,Y)
            (,Sum (+ ,First ,Second)))
       (* ,Sum ,Sum))
))

Sweet-expressions

 
defmacro Square-Sum2 (X Y)
  let
    \\
      First gensym("FIRST-")
      Second gensym("SECOND-")
      Sum gensym("SUM-")
    ` let*
        \\
          ,First ,X
          ,Second ,Y
          ,Sum {,First + ,Second}
        {,Sum * ,Sum}

Sawfish is a window manager that uses a Lisp-based scripting language called librep. The Building a Better Window Manager tutorial describes how to write programs in its Lisp-based language.

Original Lisp Here are some examples:

 
(bind-keys global-keymap
   "H-e" `(jump-or-exec "GVIM"
       ,(lambda ()
          (system
           "gvim &"))
       ,(lambda (wind)
          (display-window wind))))

(define-match-window-setter 'keymap-trans
  (lambda (w prop value)
    (declare (unused prop))
    (let ((keymap (or (window-get w 'keymap)
                      (window-put w 'keymap (copy-sequence window-keymap)))))
      (mapcar
       (lambda (pair)         ; pair of from and to keys
         (bind-keys
          keymap (car pair)
          (lambda () (interactive)
            (synthesize-event (lookup-event (cadr pair)) (input-focus)))))
       value))))

 
Here is the "infix is not default" version. Note that there is a space after the "`" and ",":
 
bind-keys global-keymap "H-e"
 ` jump-or-exec "GVIM"
       , lambda ()     system("gvim &")
       , lambda (wind) display-window(wind)

define-match-window-setter 'keymap-trans
  lambda (w prop value)
    declare (unused prop)
    let
      \\
        keymap {window-get(w 'keymap) or
                window-put(w 'keymap copy-sequence(window-keymap))}
      mapcar
        lambda (pair)         ; pair of from and to keys
          bind-keys keymap car(pair)
            lambda ()
              interactive()
              synthesize-event lookup-event(cadr(pair)) input-focus()
        value

Как на секспрах будет:

(define-syntax-rule (when p e ...)
  (if p (begin e ...) (void)))

(define-syntax-rule (yoba (p ...) ((e ...) ...))
  (begin (when p e ...) ...))

Уозникают и другие проблемы. Допустим, есть вызов (yoba (x + y)) Что пойдет на вход макросу yoba? '(x + y) или '(+ x y)? Если второе - придется в уме парсить и преобразовывать АСТ (и держать его тоже в голове), если первое - получаем существенную иррегулярность (нельзя полагаться на то, что head в выражении - всегда функция/макрос/спецформа).

ну, раз уж ты не поленился свериться со стандартами, что само по себе похвально, мог бы заодно убедиться, что в ISLISP совсем не облегчённый C++-like ILOS, отсутствует try-except-finally, defglobal/defdynamic/defconstant не имеют отношения к четкому разделению на время жизни переменных, отсутствует нормальная модульность require/provide (а также средства, которые позволили бы их реализовать) и, конечно же, нет ни слова о встраиваемости. кроме того, в стандарте CL я нигде не встречал жирной надписи !!!ЗАПРЕЩЕНО ДЕЛАТЬ РЕАЛИЗАЦИЮ МОДУЛЬНОЙ!!!.

(yoba (x + y)) = (yoba '{x + y})) = (yoba '(+ x y)) = yoba({x + y}) = что-то питонистое на t-выражениях

пойдёт первое, '(x + y), потому что S-выражения не меняются, остаются как есть. другие, C-выражения (curly-скобки) заменяются на S-выражения. здесь, возможно не хватает сплайсов — поэтому @ и , окружают пробелами, чтобы не интерпретировалось.

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

иррегулярности не получается, т.к. по синтаксису Х-выражения сразу понятно, что это за Х и как эту Х интерпретировать. C-, N-, T- выражения переводятся в S-выражения, которые потом интерпретируются.

S-выражения остаются «как есть».

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

Да откуда же понятно? (define-syntax-rule (yoba (x y z))) откуда я знаю, придет мне + вместо y или вместо x?

э не не не .

ты забываеш про Стива Рассела.

ну и вообще , что S-expr'ы не предназначались(по началу) для людей.

http://en.wikipedia.org/wiki/Steve_Russell

+ много, вот он великий дзен.

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

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

прозрачностью по ссылкам.

в ISLISP совсем не облегчённый C++-like ILOS

множественное наследование, тотальное упорядочивание по иерархии, в отличие от С++ — есть метаклассы. есть преопределённые классы, не метаклассы (например, исключения)

есть обобщенные функции, так что да, не С++.

отсутствует try-except-finally

ошибки, условия и перезапуски

(signal-condition condition continuable)

If continuable is nil, the results of attempting to “continue” (see continue-condition) are not defined except that the call to signal-condition will not return normally. If continuable is not nil, it will be possible to return from the call to signal-condition (see continue-condition). In this case, the specific value of continuable may be a string indicating the effect of continuing, or it may be the symbol t, indicating that an implementation-defined string such as «Continue with no special action.» is to be used.

(continue-condition condition [value]) transfers control and data function

“Continues” from condition by finding the call to signal-condition and arranging for it to perform a normal return of the value, which defaults to nil. The consequences are undefined if the condition is not continuable.

(with-handler handler form*) → <object> special operator

Evaluates handler, which must yield a function (called the “handler function”). The handler function is established as active handler (see §29.2) and then the forms are executed. If execution of forms finishes normally, the value of the last form (or nil if there are no forms) is returned

если (signal-condition condition nil) то это вырождается в обычный try-except-finally

defglobal/defdynamic/defconstant не имеют отношения к четкому разделению на время жизни переменных

я к тому, что глобальные и локальные формы разделены.

отсутствует нормальная модульность require/provide (а также средства, которые позволили бы их реализовать) и, конечно же, нет ни слова о встраиваемости

зависит от реализации. а встраиваемость вытекает by design и из исторических способов реализации предшественников

The following factors influenced the establishment of design goals for ISLISP:
1. A desire of the international LISP community to standardize on those features of LISP upon
which there is widespread agreement.
2. The existence of the incompatible dialects COMMON-LISP, EULISP, LE-LISP, and SCHEME
(mentioned in alphabetical order).
3. A desire to affirm LISP as an industrial language.

This led to the following design goals for ISLISP:

1. ISLISP shall be compatible with existing LISP dialects where feasible.
2. ISLISP shall have as a primary goal to provide basic functionality.
3. ISLISP shall be object-oriented.
4. ISLISP shall be designed with extensibility in mind.
5. ISLISP shall give priority to industrial needs over academic needs.
6. ISLISP shall promote efficient implementations and applications.
PUBLIC

кроме того, в стандарте CL я нигде не встречал жирной надписи !!!ЗАПРЕЩЕНО ДЕЛАТЬ РЕАЛИЗАЦИЮ МОДУЛЬНОЙ!!!.

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

минималистичное, модульное ядро CL никого не интересует.

в отличие от.

вон пример с define-syntax

(define-syntax-rule (yoba (x y z))) откуда я знаю, придет мне + вместо y или вместо x?

оттуда, что ты пишеь (yoba (x y z)) а не yoba(x y z) и не (yoba {y x z})

открой Степанова (начала программирования)

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

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

S-выражение, а не t-выражение или S+C выражение.

если (signal-condition condition nil) то это вырождается в обычный try-except-finally

в обычном try-except-finally бывает finally, а в with-handler его не бывает.

require/provide
зависит от реализации

опять ошибочка. это в стандарте CL есть зависящие от реализации require/provide, а в ISLISP их просто нет.

ага, только почему-то никто так не делает

ага, какие глупые коммонлисперы, ничего-то они не понимают.

минималистичное, модульное ядро CL никого не интересует

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

и да, если бы во время принятия стандарта уделили больше сил оттачиванию фич в ущерб совместимости с предками, велика вероятность, что CL могла постичь ещё более плачевная участь, чем схему

нет.

воплощение гну (хм ) http://c2.com/cgi/wiki?WelcomeVisitors

а википедия это как не печально справочник обиходного знания.