Главная Проблема Лиспа

> Функции в CL возвращают values.

Пример?

Пример?

Не понимаю, какой пример ты хочешь, но:

(consp (values 1 "foo" t #'null)) => nil

(integerp (values 1 "foo" t #'null)) => t

(+ 1 (values 1 "foo" t #'null)) => 2

(nth-value 3 (values 1 "foo" t #'null)) => #<Function null 41B009A2AC>

Да ну нафиг. Фестиваль вон написали на лиспе. и где развитие?

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

Т.е. причина его жизни - не в том что язык очень нужный и хороший.

Ровно то же самое я могу сказать про OCaml...

>Unicode inside. Настоящий, а не кривой как в Java.

Хм. А если мне внезапно понадобится нормализовать юникодную строку или сравнить две юникодных строки без учета диакритики или преобразовывать из/в юникод?

esrap уделывает parsec, по любому.

И чем же именно? Подходом «догадайся в рантайме, какое AST получится на выходе»?

больших проектов. Что именно интересно?

Модули. Квалифицированный импорт. Частичный импорт. Пространства имен.

А нужны?

Очень.

>Например, какой в jvm есть механизм для прозрачной передачи multiple values из функции?

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

Или как КЛевские рестарты там сделать?

Через эксцепшены. По крайней мере, создателям ABCL с ними все-равно придестя разбираться, т.е явские библиотеки любят кидать эксцепшены по поводу и без. И если их смогут подружить с CL'евскими рестартами...

> А если мне внезапно понадобится нормализовать юникодную строку или

сравнить две юникодных строки без учета диакритики или

преобразовывать из/в юникод?

Я не могу понять, что вас смущает, тут какая сложность может быть?

Подходом «догадайся в рантайме, какое AST получится на выходе»?

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

Модули. Квалифицированный импорт. Частичный импорт.

Пространства имен.

Пакеты же.

Очень.

Какие ?

так R7RS вышел же, вроде. Помню анонс на #scheme на freenode

>Предлагаю удалять темы про скобочки в LISP, так как они затрагивают религиозные чувства верующих!

предлагаю удалять темы про LISP по 4.3

p.s. С++ не нужен :D

Через эксцепшены.

Ну, а вот, собственно, рестарт дальше как делать? :)

А не подскажите, чей стандарт жирнее (в смысле больше страниц), коммонлисповый или сиплюсплюсовый?

А вообще мне в CL не нравятся глупые соглашения по именованию. Почему например defun, а не define-function? Чтобы было короче? Хорошо, а почему тогда synonym-stream-symbol вместо systresym? Вообще нет красоты в кам-он лиспе!

>никаких генераций AST.

Мой шаблон порван. Как это парсер и не генерирует AST.

Пакеты же.

В спецификации CL?

>Ну, а вот, собственно, рестарт дальше как делать? :)

А вот ХЗ как. Скорее всего, генерить байт-код, который прозрачно для программиста сохраняет состояние для областей с рестартами.

>Пакеты же.

Ы?

http://www.lispworks.com/documentation/HyperSpec/Body/11_.htm

Главныепроблемы LISP'а:
- переусложнённый синтаксис;
- отсутствие «ленивых» вычислений;
- отсутствие сопоставлений с образцом;
- отсутствие статической типизации;
- отсутствие пользовательских типов;
- трудности объяснения и понимания некоторых конструкций;
- лёгкость внесения ненамеренных ошибок в код.

Читайте, как развенчиваются мифы LISP'а: http://kmmbvnr.livejournal.com/62197.html

> Главныепроблемы LISP'а:

Бред.

- переусложнённый синтаксис;

man фломастеры

- отсутствие «ленивых» вычислений;

можно изобразить на макрах

- отсутствие сопоставлений с образцом;

есть несколько библиотек для этого

- отсутствие статической типизации;

есть

- отсутствие пользовательских типов;

бред

- трудности объяснения и понимания некоторых конструкций;

манкикодеры такие манки

- лёгкость внесения ненамеренных ошибок в код.

бред

как развенчиваются мифы LISP'а

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

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

Лично проверил?

А вот ХЗ как. Скорее всего, генерить байт-код, который прозрачно для программиста сохраняет состояние для областей с рестартами.

Ну сделать-то можно, ABCL как-то ведь выкручивается же. Но встаёт вопрос, какой кровью это даётся?

переусложнённый синтаксис;

Свойственно любому языку, который реально применяется.

отсутствие «ленивых» вычислений;

Отсутствует и проблема борьбы с ленивостью :) Уважаемый качок thesz как-то давно писал, что не осилил в проекте (эмулятор MIPS'а, что ли) побороть утечки памяти из-за ленивости. Вообще, если из-за фичи возникают левые проблемы, то это повод для размышлений.

отсутствие сопоставлений с образцом;

destructuring-bind, loop. Паттерн-матчинг а-ля ML реализуется на уровне библиотек.

отсутствие пользовательских типов;

deftype, defclass

трудности объяснения и понимания некоторых конструкций;

В пункте 1 уже было

лёгкость внесения ненамеренных ошибок в код.

Пункт 1

>Но встаёт вопрос, какой кровью это даётся?

А разве в VM CL это делается малой кровью?

А разве в VM CL это делается малой кровью?

У CL нет VM :) Вернее, не обязана быть и не везде есть. И в своём рантайме авторы имплементации CL вольны делать всё, что им угодно, а не придумывать костыли для обхода ограничений существующей VM.

> Мой шаблон порван.

Всегда рад оказать вам услугу.

Как это парсер и не генерирует AST.

Хм, разве парсер не должен парсить?

>Хм, разве парсер не должен парсить?

Собственно AST и есть результат парсинга :)

Игнат. делайте в будущем перепосты не товарища Лавсана, а товарища Казимира [Kazimir Majorinc],

Хотя, конечно, последний гораздо более адекватный и скучный :)

И, да, статейка в тему: http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf

Можно считать ее освежающим вбросом :)

> Собственно AST и есть результат парсинга :)

Мы же вроде не об этом?

>Мы же вроде не об этом?

Дык я вообще-то про то что у вышеприведенного парсера используется затейливый подход «узнай тип AST (читай топологию) в рантайме».

> у вышеприведенного парсера используется затейливый подход

«узнай тип AST (читай топологию) в рантайме».

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

херня

Подумал может ли это быть один человек и усомнился :), решил поинтересоваться

>Что-то я затрудняюсь понять.

Дейстивительно, не работавшим с комбинаторными парсерами в языках, которые поддерживают идею комбинатора.

В такой парсер *особенно при большом размере) очень просто внести ошибку, например взял и перепутал местами более мелкие парсеры. Конечно, в большинстве случаев такой парсер зафейлит на своем наборе данных. Хоть это происходит и в рантайме проблем с этим нет: будет более-менее понятное сообщение об ошибке. Но по закону подлости может случится так, что парсер не зафейлит, а поменяется структура AST. И вот тогда может получиться очень неприятная хрень и очень и очень далеко от того места, где была допущена ошибка.

В этом и заключается сущность Лиспов: сидеть в REPL'е и гонять дампы S-выражений.

Кстати, к динамической типизации это не имеет никакого отношения.

В языках, поддерживающих идею комбинатора, такая ситуация однозначно приведет к ошибкам проверки типов.

> В такой парсер *особенно при большом размере) очень просто внести

ошибку, например взял и перепутал местами более мелкие парсеры.

А, я кажется начал понимать о чём вы, действительно, я когда несколько дней сидел разбирал код pandoc всё удивлялся: и как они пишут такой код, там же так легко наделать ошибок. Оказывается спасает, что вы там говорите, а «незатейливая работа с AST». Впрочем, не спасает, ибо тот же pandoc на сложных документах часто херню порет, но да, я знаю, мир не совершенен и для любого серьёзного парсинга надо писать тесты, что хаскелисты считают ниже своего достоинства (ведь у них всё так незатейливо, зачем им тесты).

В этом и заключается сущность Лиспов

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

В языках, поддерживающих идею комбинатора

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

такая ситуация однозначно приведет к ошибкам проверки типов.

Ещё раз, pandoc на многих документах работает криво. Зато ни каких ошибок типов. Какой предлагает сделать вывод?

>Что за комбинатор?

подразумевают вещь настолько простую

Господи! Ну, конечно, комбинатор — предельно простая вещь. Его задача собирать кусок программы из кусков программы (за неимением лучшей терминологии).

Но поечему-то лисперы забывают еще об одном свойстве комбинаторов: обязательном наборе правил, которые определяют КАК комбинаторы между собой взаимодействуют. В противном случае — ошибки и потеря контроля над кодобазой.

То, что в языках типа хаскеля за этим следит система типов — совпадение. Не требуется реализовывать F-omega для того чтобы писать правила взаимодействия.

И в супер-пупер метарограммнутом лиспе, как утверждают его адепты, средств для реализации системы правил взаимодействия комбинаторов будет поболе, чем в любом языке. Т.е. реально написать парсер, который будет сообщать: «молодой человек, вы сделали парсер (string, char, int), а хотите ипользовать AST (String, String, String), не получится». И, еще раз повторюсь, никакого отношения к системе типов это не имеет.

И собственно где? Наверное проблема в том, что тогда код будет выглядеть не так шоколадно. И вообще — лень.

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

Перестаньте уже запускать абстрактные пузыри в вакуум.

молодой человек, вы сделали парсер (string, char, int), а хотите

ипользовать AST (String, String, String), не получится

Пожалуйста разъясните как это можно трактовать в контексте esrap?

Наверное проблема в том

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

>>Я вот твердо уверен, будь у CL столько же библиотек, как у .NET, или, тем более, Java

clojure же

каким боком он к ЦЛ? кложур - функциональный язык.

>Пожалуйста разъясните как это можно трактовать в контексте esrap?

Откуда я знаю как это трактовать в контексте erasp, если даже его автор не знает? Нужен какой-то DSL, позволяющий описывать структуру AST и какой-то функционал, который будет проверять возможность построения описанного AST из данного парсера.

Паттерн-матчинг а-ля ML реализуется на уровне библиотек.

а какие хорошие?

> Откуда я знаю как это трактовать в контексте erasp, если даже его

автор не знает? Нужен какой-то DSL, позволяющий описывать структуру

AST и какой-то функционал, который будет проверять возможность

построения описанного AST из данного парсера.

Мда. У меня остался один вопрос: откуда вы знаете, что владеете информацией о том, какой подход лучше? Я понял бы, если бы у вас был опыт работы с разными подходами, если бы вы сравнивали куски кода с использованием разных технологий, но нет, вы просто противопоставляете свои абстракции своему незнанию и гордо сообщаете, что ваши абстракции победили. Супер.

> В такой парсер *особенно при большом размере) очень просто внести ошибку, например взял и перепутал местами более мелкие парсеры. Конечно, в большинстве случаев такой парсер зафейлит на своем наборе данных. Хоть это происходит и в рантайме проблем с этим нет: будет более-менее понятное сообщение об ошибке. Но по закону подлости может случится так, что парсер не зафейлит, а поменяется структура AST. И вот тогда может получиться очень неприятная хрень и очень и очень далеко от того места, где была допущена ошибка.

А можно пример?

> destructuring-bind, loop

Нечитабельная громоздкая каша, пусть и мощная как ВЛ85.

Паттерн-матчинг а-ля ML реализуется на уровне библиотек.

Нормальный компактный пример в студию, плиз. Реально интересно.

> C#

WPF

Entity Framework

Visual Studio

Expression Blend

Ну и сидел бы на винде, клепал бы формочки на C# в Visual Studio. Лисп тут причём? Не интырпрайз, конечно, так что сразу несъедобно? Жуйте свои C# и Java, только не подавитесь.

> Да не, библиотеки очень нужны, а вот писать их действительно некому ( И проблема не в малом количестве библиотек, а в том что их некому писать.

Насколько хорошо в Лиспе разделяются пространства имен, чтобы эффективно писать библиотеки? Например, в Си при передаче по значению каких-либо проблем не возникает в принципе. А вот в Фортране, где передается все по имени, - сплошные грабли; в результате, библиотек нормальных (некоммерческих) как не было, так уже и не будет.

> Насколько хорошо в Лиспе разделяются пространства имен,

чтобы эффективно писать библиотеки?

Достаточно хорошо, но я не понял, какая связь между пространствами имён и соглашениях о вызове?

А вот в Фортране, где передается все по имени, - сплошные грабли;

в результате, библиотек нормальных (некоммерческих) как не было, так

уже и не будет.

В фортране используется соглашение «call-by-reference», тоже самое, что используется в Perl, который имеет бездну библиотек.

Так что в этом нет логики, а пространства имён вообще не понятно к чему приведены.

> Достаточно хорошо, но я не понял, какая связь между пространствами имён и соглашениях о вызове?

Я так понял, что осуществляется вызов объектных файлов? Тогда да - никаких проблем.

> Я так понял, что осуществляется вызов объектных файлов?

Прошу простить мою безграмотность, но что такое «вызов объектных файлов»?

> Прошу простить мою безграмотность, но что такое «вызов объектных файлов»?

Вы, лисперы, все такие высокомерные, что не можете даже на простой вопрос дать простой ответ? Или у вас там всё настолько заоблачно, что простым смертным не понять? Если в Фортране используется «call-by-reference», то вы уже не можете использовать имя «x», если оно уже используется в вызываемой библиотеке. Нормальная реализация, когда можно использовать одни и те же имена и в программе и в библиотеке. От этого можно уйти, если цеплять объектные файлы, а не сам код библиотеки. Вот у меня и интерес, нет ли подобных проблем у Лиспа?

> Вы, лисперы, все такие высокомерные, что не можете даже на

простой вопрос дать простой ответ?

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

Если в Фортране используется «call-by-reference», то вы уже не

можете использовать имя «x», если оно уже используется в вызываемой

библиотеке.

Почему? Нет. Но кажется я понял о чем вы. Это называется лексические переменные. И да, во всех современных диалектах лиспа используются лексические переменные.

Но неужели это настолько «заоблачные» понятия?

> Почему? Нет. Но кажется я понял о чем вы. Это называется лексические переменные. И да, во всех современных диалектах лиспа используются лексические переменные.

Спасибо за пояснения. Для тех, кто не читал «Practical Common Lisp», понятие «локальных» переменных как-то ближе.