(no subject)

[stas]

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

Comments

[lispnik.livejournal.com]

Лисп — это язык метапрограммирования. Это я вам как лиспник говорю.

Главное в Лиспе не функции, а макросы. А скобочки (точнее, представление программы в виде S-выражений) — это единственный способ делать нормальные макросы.

Естественно, речь идёт не о тех макросах, которые в C/C++. В лиспе макрос — это функция, которая на входе принимает одно S-выражение, а на выходе даёт другое. Т.е. все вычислимые функции доступны, а не просто подстановки в строках, как в C.

Другое дело, что ФП более удобно для написания таких вот функций, преобразующих одно выражение в другое :) Однако в Common Lisp есть и императивный ООП, и многое другое.

И ещё, надо заметить, что тот лисп, который изобрёл МакКарти, и тот, который существует сейчас (Common Lisp, Scheme) — это две большие разницы :) Я сейчас писал про современный.

[stas]

Ну я знаю, что в Common Lisp можно писать императивно. Вопрос, не является ли это такой же ересью по отношению к задумке языка, как писать императивно, например, на Прологе?

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

[lispnik.livejournal.com]

1. Нет, не является :)
2. Не всё — список. Есть ещё массивы, структуры, хеш-таблицы, объекты. Есть ещё целые произвольной точности и комплексные числа. У вас устаревшие сведения :)
3. Обычные функции работают во время работы, а макросы — во время компиляции (поэтому тут и уместна приставка мета-). Конечно, макросы могут вызывать другие функции (в этом главное отличие от большинства других макросистем).

Простой пример: для того, чтобы включить в программу на C парсер, нужно вызвать отдельную утилиту, которая описание грамматики сконвертирует в код на C. А в Лиспе для этого нужно лишь написать соотв. макрос. Другой пример — автоматическое выведение типов а-la ML.

[stas]

2. Ну, понятно, кроме списков, есть ещё атомы, их образующие.
3. Тут я не совсем понял - что значит "работают во время компиляции"? Если я на Лиспе напишу программу, которая решает квадратное уравнение - то она мне его решит при компиляции, не зная входных параметров? Нет. Или вы имеете в виду, что константные выражения в Лиспе вычисляются при компиляции? Прекрасно, ну так не только там, но не все же выражения - константные.

Простой пример: для того, чтобы включить в программу на C парсер, нужно вызвать отдельную утилиту, которая описание грамматики сконвертирует в код на C. А в Лиспе для этого нужно лишь написать соотв. макрос.

Пример непонятен. Это значит, всего лишь, что в C компилятор или там yacc не входит в RTL, а в Лиспе - входит. Ну, отлично. Уверен, что в RTL в C есть вещи, который в RTL Лиспа нет. Однако что это должно продемонстрировать мне, вот чего я не пойму - что RTL у Лиспа лучше? Ну, хорошо, лучше.

[mauhuur.livejournal.com]

> Или вы имеете в виду, что константные выражения в Лиспе вычисляются при компиляции?

Не константные. Любые. Во время компиляции доступен ВЕСЬ язык. Которым можно компилятор расширять как угодно.

[stas]

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

[mauhuur.livejournal.com]

Ну почему же неизвестны? Очень даже известны. Мы можем во время компиляции производить любые операции над собственно кодом программы. Чем это код - не данные? При этом, в таких метаязыках, как Лисп и Схема, мы используем для этих преобразований тот же язык. В C++ - это свой, отдельный язык, чисто функциональный, кстати. В метаязыках с семантикой splice-ов, опять же, можно применять сам целевой язык, как пример - метапрепроцессор Jatha для языка Java, или Template Haskell.

Всё же, рекомендую статью прочитать.

[lispnik.livejournal.com]

3. Во время компиляции работают макросы. А если входные параметры нужны в рантайме, то это нужно делать функцией.

Макросы принимают на входе данные, но генерируют код. Например, данные — грамматика, а код — парсер.

А парсер не входит в RTL Лиспа. Я не понял последний абзац. RTL вообще не причём :)

Смысл в том, что можно расширять компилятор Лиспа. Например, добавить парсер. И это ещё не самое впечатляющее.

[lispnik.livejournal.com]

2. Есть ещё функции :)

[mauhuur.livejournal.com]

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

> А чем, собственно, макрос отличается от фукнции, кроме имени, я не совсем понял.

Может, моя статейка поможет разобраться:

http://arxiv.org/abs/cs.PL/0409016

> Мне просто кажется не всегда удобным мыслить именно в этих терминах.

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

ага, а вот и флейм!

[cmm.livejournal.com]

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

это неверно.
главной бядой CL являются сектанты вроде фанатов ¨языка¨ Scheme, которые на голубом глазу сообщают лисподевственным людям херню вроде процитированного выше отрывка.

Re: ага, а вот и флейм!

[mauhuur.livejournal.com]

Херню, гойворишь? Показать реализации CL, в которых *НЕТ* корректной хвостовой рекурсии? Или сам найдёшь и извинишься?

P.S. Вообще-то я предпочитаю CL Схеме, за инкрементальную компиляцию. За неё можно простить даже раздельные пространства имён для функций и всего остального...

Re: ага, а вот и флейм!

[cmm.livejournal.com]

> Показать реализации CL, в которых *НЕТ* корректной хвостовой рекурсии?

дяденька!  окащенять меня бесполезно, я в этом деле нетренированный.  я HyperSpec читал, покуда вы в федошной песочнице друг другу письки показывали и Y-combinator трактовали.

отсутствие хвостовой рекурсии в стандарте CL — это не ¨бяда¨, это вполне сознательный фичер.

> За неё можно простить даже раздельные пространства имён для функций и всего остального

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

Re: ага, а вот и флейм!

[mauhuur.livejournal.com]

> отсутствие хвостовой рекурсии в стандарте CL — это не ¨бяда¨, это вполне сознательный фичер.

Фигнанына. Это ни разу не сознательное, а только лишь вынужденное решение. И практически все *вменяемые* компиляторы CL таки хвостовые рекурсии разворачивают. Однако:

a) закладываться на это НЕЛЬЗЯ, так как "практически" - это не "все"

b) в силу этого, ФУНКЦИОНАЛЬНО писать на CL - тоже нельзя (да и на фиг не надо), всегда, когда глубина рекурсии непредсказуема, она должна заменяться на цикл.

Имеешь что либо супротив возразить - вперёд. Иначе - не хер вякать.

Re: ага, а вот и флейм!

[cmm.livejournal.com]

> Фигнанына. Это ни разу не сознательное, а только лишь вынужденное решение.

создатели стандарта безусловно знали о хвостовой рекурсии, и не стандартизивовали её сознательно.  не потому что не могли, а потому что не хотели.

по крайней мере я склонен интерпретировать публичные высказывания того же Кента Питмана на данную тему именно таким образом (и несложный поиск на Google Groups с соответствующими ключевыми словами мне свидетель).

если есть свидетельства обратного, то давай их сюда.

> практически все *вменяемые* компиляторы CL таки хвостовые рекурсии разворачивают

и правильно делают, ибо это вполне приятная и недорогая для компилятора оптимизация.  но заметь также, что ни один *вменяемый* компилятор не производит этой оптимизации когда (> debug optimize), что характерно.

> в силу этого, ФУНКЦИОНАЛЬНО писать на CL - тоже нельзя (да и на фиг не надо)

золотые слова, в скобочках-то!

Re: ага, а вот и флейм!

[mauhuur.livejournal.com]

> создатели стандарта безусловно знали о хвостовой рекурсии, и не стандартизивовали её сознательно. не потому что не могли, а потому что не хотели.

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

> но заметь также, что ни один *вменяемый* компилятор не производит этой оптимизации когда (> debug optimize), что характерно.

Да нет, тому же OCaml по сараю, он всегда развернёт.

> золотые слова, в скобочках-то!

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

Re: ага, а вот и флейм!

[cmm.livejournal.com]

> Я понял так: не хотели заставлять тех, кто не может.

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

> тому же OCaml по сараю

а кто говорит про, прости оссподи, O'Caml?

> Так я вообще не понимаю, об что мы таки спорим

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

Re: ага, а вот и флейм!

[mauhuur.livejournal.com]

И, киста ти, Guy Steele - сектант, или как?

Re: ага, а вот и флейм!

[cmm.livejournal.com]

Guy Steele — гений и, то что называется, visionary.
Scheme — безусловно, весьма интересный академический эксперимент, воплотивший в жизнь многие на тот момент сырые и неопробованные идеи, за что ему большое спасибо.  пользоваться же я всё-таки предпочитаю CL.

Re: ага, а вот и флейм!

[mauhuur.livejournal.com]

Я тоже предпочитаю CL.

Но ещё более предпочёл бы CL с некоторыми фичами Схемы.

[stas]

Лисп позволяет мыслить в любых терминах, на любом уровне абстракции

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

[mauhuur.livejournal.com]

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

А что же в этом такого странного? Мне и в голову не приходило, что сей факт кого-то в принципе может удивлять.

> Но, возможно, я неправильно вас понимаю - что значит "метаязык"?

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

[bish0nen.livejournal.com]

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

А не получится на Прологе писать императивно - её, императивности, там просто нет, как нет родной реализации, ну скажем, regexp engine на Прологе - в виде иллюстрации факта неимперативности. Bindings к Сишным реализациям - есть, своей - нет. Пролог вообще специфичный язык, предназначенный решать эффективно одну-единственную задачу - перебор множества решений.

[trurle.livejournal.com]

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

[cmm.livejournal.com]

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