LINUX.ORG.RU

Вопрос про Лисп


0

0

Подумываю изучить Лисп. Возник вопрос про функциональные возможности этого языка, есть ли в Лиспе:

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

2. карринг (преобразование функции к функции с меньшем числом аргументов)

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

anonymous
Ответ на: комментарий от den73

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

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

anonymous
()
Ответ на: комментарий от anonymous

> борются (а также с goto)?

Борцунов - на рею. Религиозным фанатикам место в монастырях, а умный инженер будет использовать все доступные средства и технологии, взвешивая и оценивая и достоинства и недостатки. Один раз инициализируемая и потом только читаемая глобальная переменная - это не зло. goto, порождённые в результате раскрытия сложной макры (то есть, в результате работы компилятора) - это не зло.

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

anonymous
()
Ответ на: комментарий от anonymous

> Религиозным фанатикам место в монастырях

Не столь резко. Не на рею. Просто религиозные фанатики... ну... у них как бы уровень, соответствующий выбранному пути. Вообще-то в лиспе let устроен так, что с глобальными переменными работать достаточно удобно и безопасно. Сцепленность кода неустранима, она проистекает из природы вещей, из сцепленности понятий мира, описываемого программой. Можно просто эту сцепленность выражать адекватными или неадекватными средствами, а устранить её какими-то запретами не получится, никогда. Если убрать из языка прямые способы выразить сложность мира, обязательно возникнут уродливые косвенные. Посмотрите на обычный (Русский) язык. В нём есть контекст. Глобальные переменные - это тоже контекст. Контекстно-зависимый код более лаконичен. А лаконичный код поддерживать при прочих равных легче, его и писать, и читать приятнее.

> Ага. Но ведь без apply то тут как раз и не обойдёшься

Да, был неправ.

> Только вот эта макра для функций высших порядков то не работает, ага

В натуре не работает (как и любой макрос)... Не очень хорошо получилось... Надо было делать функцией, а чтобы избавиться от &rest/apply, парсить список аргументов. Rest/apply не хотелось, а парсить влом было. Но ведь можно же сделать, согласны? :)

Касаемо Математики - лень одолевает. Проблемы возникают, когда уже много написано в ленивом стиле. Далее при ничтожной ошибке возникает выражение чудовищного размера и Математика фактически виснет при попытке выдать сообщение об ошибке... Вообще, Математика мне сначала очень нравилась, а теперь я понял, что её синтаксис слишком богат и любой опечатке можно придать смысл. Нажал случайно на Escape и час искал, в чём проблема.

den73

anonymous
()
Ответ на: комментарий от Miguel

>Гм. А можно подробнее? Я что-то не шибко понял, чего ты пытаешься достичь

насколько я понял - создавать GUI с помощью ООП-подходов. непонятно только - зачем

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

> насколько я понял - создавать GUI с помощью ООП-подходов. непонятно только - зачем

Нет! Я хочу это сделать по человечески! А как не понимаю, все что я пробовал делать выглядело крайне убого в плане гибкости по сравнению с ООП. Может посоветуете тутор какой по построению гуи в целом (и созданию своих компонентов в частности) в Хаселле?

anonymous
()
Ответ на: комментарий от anonymous

> Сцепленность кода неустранима, она проистекает из природы веще [...]

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

anonymous
()
Ответ на: комментарий от anonymous

Глянул туториал по Qi. Не понравилось совсем. Это - не строго типизировнный лисп, это - просто другой язык. Начнём хотя бы с того, что в лиспе есть функция identity, которой они зачем-то придумали новое имя (видимо, не знали старого). Касаемо остального - в лиспе и так есть опциональная статическая типизация, вот пример кода, который её интенсивно использует

http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=binarytrees&a...

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

По вопросам программирования гуя. На Хаскеле - не знаю, а на лиспе - вот платные варианты:

http://www.lispworks.com/documentation/lw51/CAPUG-M/html/capiuser-m.htm

и http://www.franz.com/support/documentation/current/doc/clim-ug.pdf

den73 ★★★★★
()
Ответ на: комментарий от den73

> Это - не строго типизировнный лисп, это - просто другой язык.

Конечно же другой. Но - построенный поверх Лиспа, компилируемый прозрачно в Лисп и с Лиспом интероперабельный весьма.

> Касаемо остального - в лиспе и так есть опциональная статическая типизация

Ты не понял. Там не просто статическая типизация, там type inference, причём с настраиваемой и расширяемой системой типов. Такого почти нигде нет, кроме разве что Coq и Axiom. Не сравнивай это с примитивной ручной типизацией!

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

Для этого семантика языка должна быть другой.

> Тогда поменяется не сам язык, а только компилятор.

Язык поменяется неизбежно.

anonymous
()
Ответ на: комментарий от anonymous

Почитай про Fudgets, да или даже просто посмотри на Tcl/Tk. ООП вообще для GUI не особо подходит.

anonymous
()
Ответ на: комментарий от anonymous

> Почитай про Fudgets, да или даже просто посмотри на Tcl/Tk. ООП вообще для GUI не особо подходит.

Какая-нибудь статья в которой это аргументированно доказыватся есть?

anonymous
()
Ответ на: комментарий от anonymous

Читай про Fudgets, этого должно хватить. То, что для программиста абсолютно неООПный Tk на порядки удобнее всех этих свингов с гытыками - тоже показательно.

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

anonymous
()
Ответ на: комментарий от anonymous

> компилируемый прозрачно в Лисп

Я не понял там есть специальный компилятор (отдельная программа) выхлоп которой есть код на лиспе. Или Qi реализован как библиотека (или что там?) для Лиспа?

anonymous
()
Ответ на: комментарий от anonymous

> Я не понял там есть специальный компилятор (отдельная программа) выхлоп которой есть код на лиспе. Или Qi реализован как библиотека (или что там?) для Лиспа?

В Лиспе нет разницы между "библиотекой" и "компилятором". Любая макра - это компилятор, по сути. Но Qi умеет не только разворачивать свой код через макру, но и выдать в файл промежуточный код на Лиспе - так он собственно и бутстрапится, поскольку сам написан на Qi.

anonymous
()
Ответ на: комментарий от anonymous

> Читай про Fudgets

Читаю. Кстати, проект умер? Последняя версия 2005 г. Или они достигли божественного совершенства?

anonymous
()
Ответ на: комментарий от anonymous

>Там не просто статическая типизация, там type inference, причём с настраиваемой и расширяемой системой типов

Небольшой опыт общения с SBCL убедил меня в том, что он тоже использует выведение типов. Система типов "голого" лиспа достаточно мощна, например, можно определить тип "А или Б". Также можно определить параметрические типы, например, "отображение из А в Б". Типы функций тоже можно описать. Вот (возможно не все) примитивы работы с типами: declare, proclaim, declaim, typecase, the, coerce, deftype, typep, subtypep, type-of.

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

Достаточно наложить ограничения на существующий. Ограничения должны быть такого вида: для каждого значения, возникающего в ходе вычислений, тип должен быть с достаточной точностью либо декларирован, либо выводим из других известных типов с помощью некоего механизма. Похоже, что при разработке Common Lisp было специально предусмотрено, чтобы можно было сделать его статически типизируемым. При этом, синтаксически и семантически язык будет тождественен просто лиспу (хотя, возможно, это я не вижу каких-то дыр). Естественно, что read, eval, defun и т.п. будут особыми случаями - здесь статическая типизация невозможна в принципе, но, во всяком случае, ошибки времени выполнения можно жёстко локализовать.

А в случае Qi - просто лисп был использован для создания некоего другого языка. Непохоже, что авторы ставили перед собой задачу сделать "строго типизированный лисп". Они просто не лисперы, а ml-щики (ИМХО). И они сделали ml в лисповом синтаксисе.

den73 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.