Определение места ошибки в lisp.

grep -n "(1 " main.lisp ?

Какой же это Clojure? Clojure тебе в NetBeans или Eclipse ошибочку красненьким подчеркнёт.

А ты смотришь на ClozureCL.

> grep -n "(1 " main.lisp ?
Да уж, очень удобный метод. Особенно если таких мест много и в основном они корректные. ^)

>А ты смотришь на ClozureCL.
Верно, пока путаю постоянно.

посмотри :b сначала

Кстати, используй slime. Он всё что надо покажет.

>посмотри :b сначала
Можно поподробнее? Я в CL полный нубас.

>Кстати, используй slime. Он всё что надо покажет.
Так вроде и использую, но ничего такого не вижу.

:b в дебаггере показывает бэктрейс

>:b в дебаггере показывает бэктрейс
Ничего себе бектрейс, ещё бы в разобраться в этом выхлопе.

> grep -n "(1 " main.lisp ?

нифига.
1 может являться результатом другого s-expression.
например, ((if true then 1 else 2) ...)

только если результатом макроса

потому что CAR формы в CL не вычисляется.

а, понятно, я просто только scheme пробовал когда-то

LispWorks, кстати забавное сообщение выдает при попытке скомпилить подобные выражения:

Funny car of form: 1

Смешной ты человек! Замени (1 - 3) на (- 1 3).

Welcome to Clozure Common Lisp Version 1.4-r13122  (WindowsX8632)!
? (1 - 3)
> Error: Car of (1 - 3) is not a function name or lambda-expression.
> While executing: CCL::TOPLEVEL-EVAL, in process listener(1).
> Type :POP to abort, :R for a list of available restarts.
> Type :? for other options.

>Смешной ты человек!
Ты смешной, читаешь, но не понимаешь.

Это еще надо посмотреть, кто тут смешной.

Я считаю, что Lisp - очень хороший язык. Если он называется Scheme, и есть в нем не используют макры (кроме определенных в самом компиляторе).

А вот теперь представь, что этот бред (1 - 3) - это результат подстановки какой-то макры. Как ты эту ошибку найдешь не прикладывая усилий? Никак. Макры не нужны.

Между прочим, большинство приличных реализаций Схемы используют для кода вовсе не списки (ага, ага, все кто вещал про «код = данные» в пролете). Советую подумать над тем, на фига в стандарте есть функции datum->syntax-object и syntax-object->datum.

Эти самые syntax-object обычно отличаются от списков тем, что там навешанны метаданные - файл, строка, символ. Поскольку немногочисленные используемые макросы гигиенические, то эти метаданные сохраняются, и приличный компилятор Схемы просто, по человечески, как любой нормальный компилятор Си, просто скажет, в какой строке какого файла есть ошибка.

Common Lisp этого не умеет.

> Common Lisp этого не умеет.

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

>>Смешной ты человек!

Ты смешной, читаешь, но не понимаешь.

Это такой вид троллинга? Покажи весь код...

> имя файла точно скажет, и выражение, на котором спотыкается тоже покажет

Но не номер строки.

так что найти конкретное место в файле не проблема

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

разработка идёт прежде всего через REPL

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

Некоторые проблемы могу быть с сайд-эффектами макросов, но если их не использовать

А я о чем толкую? Язык без макросов лучше чем язык с макросами. На крайний случай, если макросы используются для реализации компилятора самого языка, они должны быть гигиеническими, это позволяет отследить все преобразования и сохранить информацию для отладки. Scheme рулит.

>> разработка идёт прежде всего через REPL

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

раздельнеая компиляция и REPL вещи ортогональные.

> раздельнеая компиляция и REPL вещи ортогональные.

Я про инкрементальную компиляцию говорю.

> Я считаю, что Lisp - очень хороший язык. Если он называется Scheme, и есть в нем не используют макры (кроме определенных в самом компиляторе).

Ты тоже хочешь меня рассмешить? :)

Мне очень нравятся макросы CL. В них сила. Про схему сказать не могу, поскольку не знаю ее настолько, чтобы сравнить.

Скорее всего у человека где-то минус стоит не в том месте в им же написанном макросе. Надуманная проблема.

>> раздельнеая компиляция и REPL вещи ортогональные.

Я про инкрементальную компиляцию говорю.

Все равно ортогональные

>Скорее всего у человека где-то минус стоит не в том месте в им же написанном макросе. Надуманная проблема.

Учитывая вот это: «Booster» и вот это: «Я в CL полный нубас. » мне приходи на ум, что там в коде так и написано (1 - 3)

> Но все равно нужны лишние телодвижения. А хороший разработчик -

ленивый разработчик, и он выберет тот инструмент, который не

заставляет его делать ненужные действия.

Правильно, и инструмент этот называется REPL помноженный на силу SLIME.

Язык без макросов лучше чем язык с макросами.

А обоснование? Макросы с сайд-эффектами могу доставить некоторые неудобства, но раз их используют, то значит получаемые преимущества превышают недостатки, в реальной практике - превышают многократно.

> Мне очень нравятся макросы CL. В них сила

А уж в ассемблере сколько силы! Но все же лучше пользоваться более надежными и безопасными средствами.

Скорее всего у человека где-то минус стоит не в том месте в им же написанном макросе. Надуманная проблема.

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

> Не надуманная проблема, а вполне реальная проблема

отладки этих ваших макросов

Ух ты! Что libastral уже допили? Откуда инфа?

И вообще, не нравятся макросы - ну не используй их, кто тебя заставляет?

И, кстати, интересно сколько кода ты написал на CL, а сколько на Scheme - на основе чего делаются такие выводы?

>Учитывая вот это: «Booster» и вот это: «Я в CL полный нубас. » мне приходи на ум, что там в коде так и написано (1 - 3)
Банный лист в своём репертуаре. Неужели так сложно понять, что меня интересует техника определения места ошибки. Кто здесь тролль, так это Вы, уважаемый.

dave

Скорее всего у человека где-то минус стоит не в том месте в им же написанном макросе. Надуманная проблема.

Я не просил найти ошибку.

archimag

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

Разрабатывать так, чтобы не было нужды искать ошибки? Если-бы всё в мире было так идеально.

> Разрабатывать так, чтобы не было нужды искать ошибки?

Если-бы всё в мире было так идеально.

При использовании SLIME я делаю так: редактирую файл с исходным кодом, точнее конкретное выражение в файле, выражение закончено - ставлю курсор где-то в этом выражении и нажимаю C-M-x - это команда отправляет выражение в REPL. Если в коде ошибка - то тут же выскочит отладчик и я сразу вижу, что я сделал что-то не так, ну а стэк вызовов помогает понять что. Поскольку я так делаю абсолютно для всего кода, который пишу, то проблемы при загрузке файла бывают в основном только из-за макросов с сайд-эффектами. Ещё бывают иногда опечатки, т.е. просто где-то например поставил ( и забыл про неё, но это находится тривиально и говорить тут особо не о чем. Для понимания проблем макросов с сайд-эффектами рекомендую вот эту статью: http://lisper.ru/articles/eval-when .

>>Скорее всего у человека где-то минус стоит не в том месте в им же написанном макросе. Надуманная проблема.

Я не просил найти ошибку.

Так чего ты тогда хотел по такому выхлопу? А так, да, slime обычно показывает хорошо место ошибки. К тому же лисп предполагает метод постепенной разработки. Как в форте, например. Поэтому обычно знаешь, где может произойти ошибка.

> Не надуманная проблема, а вполне реальная проблема отладки этих ваших макросов, которыми никто по нормальному пользоваться и не умеет.

Решил покуситься на святую святых CL - на сами макросы? Думаешь, интересно будет потроллить? ;)

>Так чего ты тогда хотел по такому выхлопу?
Читаем нулевой пост.

А так, да, slime обычно показывает хорошо место ошибки.

Так не показывает же.

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

По-моему не дело языка навязывать метод разработки.

Мир не идеален. Кто-то случайно или преднамеренно внёс ошибку и что тогда?

>>А так, да, slime обычно показывает хорошо место ошибки.

Так не показывает же.

Дело может быть в самом Clozure CL (кстати, почему ты его путаешь с clojure?). Попробуй взять SBCL, или CLISP, или Allegro CL с LispWorks. Может быть, они дружелюбнее в диагностике?

При использовании SLIME я делаю так: редактирую файл с исходным кодом, точнее конкретное выражение в файле, выражение закончено - ставлю курсор где-то в этом выражении и нажимаю C-M-x - это команда отправляет выражение в REPL. Если в коде ошибка - то тут же выскочит отладчик и я сразу вижу, что я сделал что-то не так, ну а стэк вызовов помогает понять что.

Вот что я вижу:

java.lang.Exception: Unable to resolve symbol: defun in this context (NO_SOURCE_FILE:1)
  [Thrown class clojure.lang.Compiler$CompilerException]

Restarts:
 0: [ABORT] Return to SLIME's top level.
 1: [CAUSE] Throw cause of this exception

Backtrace:
  0: clojure.lang.Compiler.analyze(Compiler.java:4420)
  1: clojure.lang.Compiler.analyze(Compiler.java:4366)
  2: clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:2828)
  3: clojure.lang.Compiler.analyzeSeq(Compiler.java:4594)
  4: clojure.lang.Compiler.analyze(Compiler.java:4405)
  5: clojure.lang.Compiler.analyze(Compiler.java:4366)
  6: clojure.lang.Compiler.eval(Compiler.java:4646)
  7: clojure.core$eval__5236.invoke(core.clj:2017)
 --more--

> Вот что я вижу:

Вообще у сложилось впечатление что slime не очень дружелюбен, в особенности для тех, кто не юзает emacs. Да и подвиснуть так и норовит, мучаюсь с ним.

Дурачок, это не slime и clojure - это не clozure cl.

>Дурачок, это не slime и clojure - это не clozure cl.
Ну как с такими общаться, это же полные неадекваты.

Вот ёлки, у тебя всё таки Clojure! Тогда я пас, ничего про него не знаю (кроме того, что это такая вариация на тему лисп).

Вообще у сложилось впечатление что slime не очень дружелюбен,

в особенности для тех, кто не юзает emacs.

Я вообще не знал, что slime поддерживает Clojure :) Но если поддерживает, то совсем недавно и вполне вероятно, что пока криво. Ну и c emacs-ом надо уметь работать, это да...

Ты, вообще-то, clojure от Clozure CL различаешь?

У меня Clojure Box, а компилю с помощью Clozure СL отдельной командой. ^). Такой бардак потому-как ещё не разбираюсь во всём этом. Да к тому-же сейчас за машиной, на которой винда. ^)

>Ты, вообще-то, clojure от Clozure CL различаешь?
Вопрос конечно интересный. ^)

> У меня Clojure Box, а компилю с помощью Clozure СL отдельной командой.

Млять, это же разные языки! Как можно, компилятором одного языка компилировать другой?

Качал отсюда - http://trac.clozure.com/ccl
Написано, что clozure.

>Млять, это же разные языки! Как можно, компилятором одного языка компилировать другой?
Чего?

> Чего?

clojure != clozure

Судя по

java.lang.Exception: Unable to resolve symbol: defun in this context (NO_SOURCE_FILE:1) 
  [Thrown class clojure.lang.Compiler$CompilerException] 

Ты пытаешься скомпилировать программу на CL - Common Lisp с помощью компилятора clojure - совершенно другого языка, и кто тут неадекват?

> У меня Clojure Box, а компилю с помощью Clozure СL отдельной командой. ^)

Ну, вот. Сам запутался и нас чуть не запутал. Это разные реализации разных языков. Компилировать одно другим нельзя. Почитай википедию, например. Хотя мне она не нравится, но для первого поверхностного знакомства cойдет.

И хорошо подумай. Может быть, лисп - это не твое.

>Ты пытаешься скомпилировать программу на CL - Common Lisp с помощью компилятора clojure - совершенно другого языка, и кто тут неадекват?
Я же сказал, что я только начинаю изучать лисп. И компилю я с помощью Clozure, Clojure Box использую только как редактор. Спасибо, что объяснили, что это разные языки и так делать не стоит.

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