Re:[lisp] Приколы нашего городка

http://paste.lisp.org/display/79836

Как то так

Re:[lisp] Приколы нашего городка

http://www.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Body/mac_defclass.html#defclass

> The consequences of attempting to store in a slot a value that does not satisfy the type of the slot are undefined.

Re:[lisp] Приколы нашего городка

Это CLISP у тебя? Просто в CMUCL (а соответственно и в SBCL) контроль типов есть.

http://common-lisp.net/project/cmucl/doc/cmu-user/extensions.html#toc68

Re:[lisp] Приколы нашего городка

Упс. Слона то я спросони и не заметил.

Надо пологать, что поведение с (optimize (speed 3) (safety 0)) тоже сугубо индивидуально для конкрентой реализации?

Re:[lisp] Приколы нашего городка

Это CLISP у тебя? SBCL. Но в clisp и ecl таже фигня. Спициально запустил, что бы провирить. Я вообще вначале подумал, что это у меня от недосыпу.

Re:[lisp] Приколы нашего городка

Очень странно... От SBCL я никак не ожидал такого. Да и не понятно, почему: он же форкнулся от CMUCL, а там по ссылке написано, что контроль есть. Выходит от динамической типизации в лиспе никуда не уйдешь, и мой аргумент в нашем споре (ты помнишь) все-таки правильный.

Re:[lisp] Приколы нашего городка

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

Re:[lisp] Приколы нашего городка

> Выходит от динамической типизации в лиспе никуда не уйдешь

легко входит, легко выходит... При (declaim (optimize (safety 3))) sbcl на пример со строкой очень даже грязно выругается. Другие имплементации впрочем могут проглотить, ибо согласно пророчеству "are undefined". Собственно, никто не мешает сотворить (defmethod (setf sl1) :before (new-sl1 (self cl1)) <сюда пихать проверку типа-и-всего-чего-угодно>), поюзать MOP'овские slot-definition-type, поюзать :writer в качестве опции слота (не забывая, что writer-ов может быть превеликое множество), итд итп. Самое главное - не забывать, что лисп это не язык наподобие висуалвасика но с преламут^Wскопками, а конструктор языков.

Re:[lisp] Приколы нашего городка

> Надо пологать, что поведение с (optimize (speed 3) (safety 0)) тоже сугубо индивидуально для конкрентой реализации?

Да, поскольку это сильно зависит от целевой платформы, а стандарт на этот счёт предоставляет достаточную анарх^Wсвободу.

Re:[lisp] Приколы нашего городка

Можно было догадаться уже по поведению sbcl c считалкой crc, которая заработало только с (optimize (safety 0)), а до этого ругалась на пере^Wнесоответствие значения зявленному (ungigned-byte 16).

З.Ы. Я так понимаю, что для пущей надёжности надо ещё делать (declare (type <bla-bla> <имена-слотов>)) что бы компи^Wреализация сабжевого надязыка не страдала фигнёй по ходу пьесы?

Re:[lisp] Приколы нашего городка

> (declare (type <bla-bla> <имена-слотов>))

нет, этого делать не нужно, ибо слот не является аналогом переменной-члена класса в с++ или жабе. См. например cells.

> а до этого ругалась на пере^Wнесоответствие значения зявленному (ungigned-byte 16).

Потому что в лисп более сложная система типов, для корректной работы более пригодна проверка на типы в виде subtypep, и ещё могут действовать дополнительные ограничения. Например, при наследовании класса :type не отменяет задекларированный родителем тип, а накладывает на него дополнительные ограничения. Это особенно заметно в хитросплетениях vector, array, sequence, итп.

Но вообще задавать и проверять типы на каждый чих неполезно. Хотя указание типа в основном служит подсказкой для оптимизатора, необдуманное насильственное указание типа может наоборот значительно ухудшить быстродействие. На эту тему вроде было обсуждение на ЛОР0.

Также проверка типа не очень полезна из-за наличия мультиметодов, да и при цепочной проверке списка из разнотипных элементов более удобным оказывается нечто вроде (cond ((subtypep ...))).

Re:[lisp] Приколы нашего городка

>Потому что в лисп более сложная система типов, для корректной работы более пригодна проверка на типы в виде subtypep, и ещё могут действовать дополнительные ограничения. Например, при наследовании класса :type не отменяет задекларированный родителем тип, а накладывает на него дополнительные ограничения.

Что-то вроде (and fixnum (integer 0 123)) ?

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

У меня вольное переложение генератора парсеров двоичных файлов из "практикума", но для хитрых протоколов обмена железок через rs422/485, там таких тонкостей, пока, не предвидится, а вот перформенс был бы желателен. Хотя, если продолжить тему необдуманного прибивания типов, то меня как то поразил один из примеров mcclim, падающий в дебагер от того, что 0 не float, то ли от того, что 0.d0 не целое.

Re:[lisp] Приколы нашего городка

> Что-то вроде (and fixnum (integer 0 123)) ?

да, именно так

> перформенс был бы желателен

Оптимизатор sbcl при надлежаще выставленом declaim optimize генерит множество примечаний относительно возможностей для оптимизации. Оптимизировать довольно сложно, тонкостей много, а код без явных огрехов типа излишних использований функций nth или last или излишних напрягов GC довольно быстр (хотя старт может быть долгим из-за загрузки ВМ, но это принципиальная сложность), так что без реальной надобности браться за низкоуровневую оптимизацию путём ограничения в типах не рекомендую.

> меня как то поразил один из примеров mcclim, падающий в дебагер от того, что 0 не float, то ли от того, что 0.d0 не целое.

Чего же тут удивительного? Это разные типы, и ведут себя по-разному, и если неявное преобразование запрещено, значит нельзя. Тебя ведь не удивляет, что (/ 1 3) и (/ 1.0 3.0) дадут принципиально разный результат?

Re:[lisp] Приколы нашего городка

Я и привёл пример и mcclim-examples как пример, уж извините за пример-примерный.

Однако, как я уже писал, у меня сейчас задача как раз такая, где прибивание типов как раз показано (около половины операций состоит из (setf (ldb (byte ...))), плюс всякие crc и коды Рида-Соломона.

Кстати, не присоветуете какого нить мануала по написанию генераторов парсеров двоичных протоколов обмена, кроме как чтения сырцы clx до просветления?

З.Ы. Спасибо за разъяснения.

Re:[lisp] Приколы нашего городка

s/сырцы/сырцов/ - не проснулся ещё

Re:[lisp] Приколы нашего городка

> Я и привёл пример и mcclim-examples как пример, уж извините за пример-примерный.

пример вполне корректен и хорош

> Кстати, не присоветуете какого нить мануала по написанию генераторов парсеров двоичных протоколов обмена, кроме как чтения сырцы clx до просветления?

боюсь, что нет.