LINUX.ORG.RU

Common Lisp: eval-when

 ,


2

1

Мужики, поясните за eval-when. В целом, эмпирически, я представляю как работает eval-when в разрезе compile-file, (load .lisp) и (load .fasl), но таблички в HyperSpec-е и CLtL2 вообще никак соотнести со своими представлениями не могу. В частности, не могу понять что из-себя compile-time-too и non-compile-time режимы представляют и когда они наступают. В описании какие-то мутные, если можно так сказать, определения.

Для удобства, приведу таблички здесь: http://www.lispworks.com/documentation/HyperSpec/Body/03_bca.htm

| CT  | LT  | E   | Mode | Action   | New Mode         |
|-----+-----+-----+------+----------+------------------|
| Yes | Yes | -   | -    | Process  | compile-time-too |
| No  | Yes | Yes | CTT  | Process  | compile-time-too |
| No  | Yes | Yes | NCT  | Process  | non-compile-time |
| No  | Yes | No  | -    | Process  | non-compile-time |
| Yes | No  | -   | -    | Evaluate | -                |
| No  | No  | Yes | CTT  | Evaluate | -                |
| No  | No  | Yes | NCT  | Discard  | -                |
| No  | No  | No  | -    | Discard  | -                |

https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node68.html#SECTION00933000000...

| LT  | CT  | EX  | CTTM | Action                                |
|-----+-----+-----+------+---------------------------------------|
| yes | yes | -   | -    | process body in compile-time-too mode |
| yes | no  | yes | yes  | process body in compile-time-too mode |
| yes | no  | -   | no   | process body in non-compile-time mode |
| yes | no  | no  | -    | process body in non-compile-time mode |
| no  | yes | -   | -    | evaluate body                         |
| no  | no  | yes | yes  | evaluate body                         |
| no  | no  | -   | no   | do nothing                            |
| no  | no  | no  | -    | do nothing                            |

Статью (на русском) Fare про eval-when знаю, но считаю её ещё более запутанной, чем описания в первоисточниках.

P.S. У меня вот такие таблички получились:

| :compile-toplevel | :load-toplevel | compile-file   | load .fasl |
|-------------------+----------------+----------------+------------|
| -                 | -              | -              | -          |
| +                 | -              | eval           | -          |
| -                 | +              | compile        | eval       |
| +                 | +              | eval & compile | eval       |

| :execute | load .lisp     |
|----------+----------------|
| -        | -              |
| +        | eval           |
Это всё для случая, когда eval-when на верхнем уровне. В подформах для eval-when имеет смысл только :execute. Если стоит — обрабатываем, если нет — nil.



Последнее исправление: deadlock (всего исправлений: 2)
Ответ на: комментарий от Oxdeadbeef

Ну редиски значит.

Угу. И не «в здравом уме» (с) твоя цитата.

Можешь взять metabang-bind. Его определённо используют через use. Не будешь же писать metabang-bind:bind.

А 15.01.2012 внезапно добавился *unused-declarations-behavior*. При этом номер версии даже не изменился.

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

Опять же кто будет делать (:use #:hunchentoot)?

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

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

остальные беру из опенсорса за которыми потом слежу в своем репозитории. Библиотеки из Quicklisp напрямую на продакшене не использую.

Получаем DLL hell в его худшей версии. Это значит, что пользователь может использовать не больше одной программы на CL без переустановки.

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

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

Мой пользователь получает конечный продукт — готовый бинарник с сопутствующими ресурсами. Ни о каком CL он даже и не знает.

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

:import-from решает. Иначе ССЗБ.

Это для metabang-а хорошо. Когда из пакета потребно 2-3 символа. А в прочих у всех (почти) будет :use. Вне зависимости кем они будут в твоих глазах :)

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

А в прочих у всех (почти) будет :use. Вне зависимости кем они будут в твоих глазах :)

у всех (почти)

Если у них что-то сломается это не моя проблема — у меня все работает. Если кто-то не умеет пользоваться инструментом разработки — это их проблема — у меня все работает.

А вообще советую посмотреть на UIOP:DEFINE-PACKAGE, там многие проблемы CL:DEFPACKAGE разруливаются.

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

советую посмотреть на UIOP:DEFINE-PACKAGE, там многие проблемы CL:DEFPACKAGE разруливаются

Я же говорю: CL - язык хороший, стандартная библиотека плохая (устаревшая).

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

конечный продукт — готовый бинарник с сопутствующими ресурсами

Видимо единственно разумный вариант. Хотя для _linux_.org.ru как-то проприетарщиной попахивает.

Ни о каком CL он даже и не знает.

А как же Open Source... GPL/LLGPL на многие пакеты?

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

пользуйтесь чем хотите. мне пофиг.

Да я, собственно, не тебя убеждаю. А тех, кто читает нашу с тобой дискуссию. В Racket разработчиков маловато... :-)

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

Хотя для _linux_.org.ru как-то проприетарщиной попахивает.

как будто это что то плохое :)

А как же Open Source... GPL/LLGPL на многие пакеты?

Я GPL библиотеками не пользуюсь. Вменяемый разработчик _библиотеки_ будет использовать MIT, BSD или подобные. Конечное приложение может быть GPL, тут вроде все нормально.

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

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

Без (safety 0) (такого режима в ракетке просто нет) ракетка стабильно быстрее CL.

В CL есть declare. В Racket либо приходится переписывать на Typed Racket, либо вручную проставлять unsafe-fx+ и прочее. В остальном согласен.

monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от monk

В CL есть declare. В Racket либо приходится переписывать на Typed Racket, либо вручную проставлять unsafe-fx+ и прочее. В остальном согласен.

Ну в итоге это эквивалентно (safety 1). А вот, например, отключить проверки на аргументы ф-й в ракетке нельзя, а в CL с (safety 0) можно спокойно передать два аргумента в ф-ю с одним, и рантайм даже не вякнет.

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

Ну в итоге это эквивалентно (safety 1).

Согласен. Я к тому, что в реальных программах в Racket очень редко вставляют unsafe даже там, где можно. Поэтому крупные программы медленнее, чем могли бы быть.

С другой стороны, в CL наблюдается излишнее использование CLOS даже там, где он абсолютно не нужен, с соответствующим влиянием на производительность.

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