Haskell, Lisp и многословие

Не могли бы вы подробнее рассказать о «программировании на Haskell гораздо менее интерактивно». Разве GHCi не предоставляет все, что вам нужно?

@JohannesGerer: Я не пробовал, но, насколько я прочитал, GHCi не является оболочкой в ​​работающем образе, где вы можете переопределить и расширить произвольные части всей программы во время ее работы. Кроме того, синтаксис Haskell значительно усложняет программное копирование фрагментов программы между repl и редактором.

От Конора Макбрайда, цитируемого Доном Стюартом: «Мне нравится думать, что типы искажают нашу гравитацию, так что направление, в котором мы должны двигаться [для написания правильных программ], становится« под гору ». Система типов позволяет на удивление легко писать правильные программы… см. эта почта и его повторные публикации.

Функции высокого порядка не могут заменить макросы, и, фактически, в CL почему-то есть и то, и другое. Настоящая сила макросов в CL заключается в том, что они позволяют разработчику вводить новые языковые функции, которые помогают лучше выразить решение проблемы, не дожидаясь выхода новой версии языка, как в Haskell или Java. Например, если бы у Haskell была такая возможность, авторам Haskell не нужно было бы писать расширения GHC, если бы они могли быть реализованы самими разработчиками в виде макросов в любое время.

@mljrg У вас есть конкретный пример? См. Комментарии к ответу Hibou57 ниже, где предполагаемый пример оказался сомнительным. Мне было бы интересно узнать, что вы имеете в виду (например, код Haskell с макросами и без них).

Уберите каррирование из Haskell. Не могли бы вы реализовать это с тем, что осталось бы в Haskell? Другой пример: предположим, что Haskell не поддерживает сопоставление с образцом, не могли бы вы добавить его самостоятельно, чтобы разработчики GHC не поддерживали его? В CL вы можете использовать макросы для расширения языка по желанию. Я предполагаю, что именно поэтому CL язык не изменился со времени своего стандарта еще в 90-х, тогда как Haskell, похоже, имеет нескончаемый поток расширений в GHC.

Liskell ссылка на сайт мертв, но в наши дни есть Hackett.

Схема (один из двух основных диалектов LISP) действительно имеет ленивое вычисление, хотя это не по умолчанию, как в Haskell.

(defmacro doif (x y) `(если, x, y))

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

Эй, у вас случайно есть название той статьи Костанцы, на которую вы ссылались? Похоже, этот файл был перемещен.

Возможно, это был такой: p-cos.net/documents/dynatype.pdf

Обратите внимание, что haskell также поддерживает синтаксис префикса, но я бы сказал, что использование monad >> = было бы очень некрасивым. Также я не согласен с тем, что нечистота является благословением: P

Мне нравится это примечание: Мы еще не собрали эмпирических данных, вызывает ли эта проблема серьезные проблемы в реальных программах.

Ни один из примеров в этой статье (Pascal Costanza, Динамический и статический набор текста - анализ на основе шаблонов) не применим к Haskell. Все они специфичны для Java (или, точнее, специфичны для "объектно-ориентированное программирование"), и я не вижу ни одной из этих проблем, возникающих в Haskell. Точно так же все ваши другие аргументы спорны: можно также сказать, что Haskell «чистый и, следовательно, больше подходит для быстрого прототипирования», что синтаксис префикса не является обязательным, что у него нет большого количества компиляторов, которые делают разные вещи , так далее.

Эта статья действительно почти не имеет отношения к Haskell. "dilbert = dogbert.hire(dilbert);" ?? Я сомневаюсь, что многие программисты на Haskell могут даже прочитать это, не вздрогнув.

Не совсем (AFAIK), но вы можете сделать что-то подобное, изменив функцию (при условии, что она рекурсивна), чтобы функция рекурсивно вызывалась в качестве параметра (!), А не просто вызывала себя по имени: haskell.org/haskellwiki/Memoization

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

Все в Haskell запомнено и, вероятно, встроено, когда это необходимо по умолчанию компилятором Haskell.

Это распространенное заблуждение. Да, в Haskell лень означает, что вам не нужны макросы, когда вы не хотите оценивать некоторые части выражения, но это только самое тривиальное подмножество всех применений макросов. Google для "Свинья до Perl" за доклад, демонстрирующий макрос, который нельзя сделать ленивым. Кроме того, если вы делать хотите, чтобы какой-то бит был строгим, вы не можете сделать это как функцию - отражая тот факт, что delay Scheme не может быть функцией.

@ Эли Барзилай: Я не считаю этот пример очень убедительным. Вот полный, простой перевод слайда 40 на Haskell: pastebin.com/8rFYwTrE

@ Рид Бартон: А? Основная идея этого документа - создание макрос, который на самом деле является небольшим DSL для определения автоматов, которые "компилируются" в код схемы. Ваш код, OTOH, является своего рода простым переводом кода, но (а) он использует поиск по таблице, о котором Шрирам говорит в начале, и, что гораздо важнее, (б) вы используете простой Haskell, и результат все еще далек от определения такого DSL. AFAICT, единственное, что это демонстрирует, это «легко написать такой код, проще, когда вы можете использовать значения функций в таблице». То есть, к макросам мало что относится.

@ Эли Барзилай: Я вообще не понимаю вашего ответа. acceptявляется (E) DSL. Функция accept является аналогом макроса, описанного на предыдущих страницах, а определение v точно аналогично определению v на схеме на слайде 40. Функции Haskell и Scheme вычисляют то же самое с той же стратегией оценки. В лучшем случае макрос позволяет вам раскрыть оптимизатору большую часть структуры вашей программы. Вряд ли вы можете назвать это примером, когда макросы увеличивают выразительную силу языка так, как это не воспроизводится ленивым вычислением.

Я не слежу ни за чем из этого. Прежде всего, да - accept - это функция, которая выполняет работу, но это не DSL, это функция, как и все другие функции, и такие вещи, как использование ее во всех подсписках или необходимое использование where с его собственная область видимости - это именно то, что делает макрос ненужным. Что касается ленивой оценки - вы не используете ее каким-либо существенным образом, поэтому я не понимаю, насколько уместен весь этот аргумент.

@Eli Barzilay: В гипотетической ленивой схеме вы могли бы написать это: pastebin.com/TN3F8VVE Мое общее утверждение состоит в том, что этот макрос мало что вам дает: немного другой синтаксис и более простое время для оптимизатора (но это не имеет значения для «достаточно умного» компилятор "). Взамен вы загнали себя в ловушку невыразительного языка; как определить автомат, который соответствует любой букве, не перечисляя их все? Кроме того, я не знаю, что вы имеете в виду, говоря «использовать его во всех подсписках» или «обязательное использование where с его собственной областью действия».

Рид: (а) ленивый план не является гипотетическим - один из них был частью Racket в течение нескольких лет; (б) факт, что макросы все еще полезны, есть хорошая подсказка; (c) то, что вы написали, также показывает, почему макрос полезен - он не использует его и, следовательно, не является тем DSL, о котором говорит Шрирам; (г) под «использованием его в подсписках» и т. д. я имел в виду, что у вас есть определенные требования к вашему «DSL», которые исходят от реализации (например, использование accept) - это одна из причин, почему это нет как DSL;

(e) Иллюзия того, что лень делает макросы управления потоком (те, которые не имеют новых привязок) избыточными, может рассматриваться как фикция, если вы думаете о добавлении строгого оператора к ленивому языку - для использования такого оператора требуются специальные формы (и макросы ) тоже; (е) еще один момент: если в Haskell макросы не нужны, почему они у него есть? (И даже до TH использовался CPP.)

Наконец, (ж) убедитесь, что вы ловите себя на «невыразительном языке» - все дело в DSL, а не в GPL. Очевидно, что можно написать более сложный макрос, который будет иметь выражения Scheme (например, предикат для символа, вместо того, чтобы перечислять их все), но в этом примере это выходит за рамки DSL.

Хорошо, я сдаюсь. По-видимому, ваше определение DSL - это «аргументы макроса», и поэтому мой пример с ленивой схемой не является DSL, несмотря на то, что он синтаксически изоморфен оригиналу (automaton становится letrec, : становится accept, -> становится ничем в этой версии). Что бы ни.

Ссылка в этом посте кажется неработающей @ Hibou57, не могли бы вы проверить и при необходимости исправить свое сообщение?

@batbrat, исправлено, и спасибо, что уведомили меня о проблеме (они изменили расположение своих URL-адресов на этом сайте).