В общем-то, достаточно сделать структуру данных и функции, выполняющие операции над этими структурами. Операции CL:+, CL:-, CL:*, CL:/ перегрузить не удастся.

Меня этот вопрос занимал года три назад, но тогда был в лиспе ещё большим лохом и оставил решение задачи на потом. И вот, время пришло :)

>В общем-то, достаточно сделать структуру данных и функции, выполняющие операции над этими структурами. Операции CL:+, CL:-, CL:*, CL:/ перегрузить не удастся.

Что-то я не уловил смысла финта с затенением (shadow) символов из common-lisp: более менее "естественно" это будет выглядеть только внутри данного пакету, а снаружи будет смотреться несколько странно и сбивать с толку новичков, ибо понять разницу между common-lisp:* и mypackage:* может оказаться не так просто. В общем, здесь нужно просто писать функции типа money+, money* и т.п.

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

> Оно понятно, но согласись (+ $1.12 $23.45) выглядит лучше чем (m+ $1.12 $23.45)

http://lisper.ru/apps/format/150 - сам код

> Интересный вариант с set-macro-character внутри себя, но мне кажется это лишнее, мы ведь когда вводим - уже имеем точность в колличестве знаков после запятой

Мы вводим текстовое представление. Когда парсер его считает и приведёт к внутреннему IEEE754 представлению, то 10.12 из текста программы легко превращается в 10.11999999999 или 10.1200000001.

> Что-то я не уловил смысла финта с затенением (shadow) символов из common-lisp: более менее "естественно" это будет выглядеть только внутри данного пакету, а снаружи будет смотреться несколько странно и сбивать с толку новичков, ибо понять разницу между common-lisp:* и mypackage:* может оказаться не так просто. В общем, здесь нужно просто писать функции типа money+, money* и т.п

s/нужно/можно/, да? :)

> Оно понятно, но согласись (+ $1.12 $23.45) выглядит лучше чем (m+ $1.12 $23.45). Да и тут бы с++овый подход сработал, будь + generic функцией, специализировал бы ее нужными типами и все, но наверно тормозило бы.

> http://lisper.ru/apps/format/150 - сам код

Т.е. для единицы с точностью 8 знаков после запятой придётся вводить 1.00000000?

> лучше скажи, сохраненный код у тебя долго хранится

> s/нужно/можно/, да? :)

>Т.е. для единицы с точностью 8 знаков после запятой придётся вводить 1.00000000?

> Не, они не удобны если надо 10 строк сохранить

> А вот в твоем варианте бага)

> Но у меня вот еще вопрос возник, можно ли заставить лисп печатать по человечески твой вариант, имею ввиду аналог :print-function для структур? Я собственно структуру только из-за него и использовал.

Неа.

>Не, они не удобны если надо 10 строк сохранить

Кстати, давно хотел, да не знаю как, сделать нечто вроде

для точки. Ну, то есть: $12.34 - макрочары подчёркнуты. Вообще, сложилось впечатление, что в cl символ #\. занимает некое особое место, потому что (defvar ... 34) - "too many dots".

>На github есть сервис gist, который предоставляет очень удобные средства хранения маленьких кусочков кода и даже нескольких файлов. Причем сохраняются они в git-репозитории, но с удобным веб-интерфейсом.

> Религия не позволяет, я уже в секте hg

>Ну, с этим надо что-то делать, ибо в мире CL поклонников hg, слава богу, особо не замечено и git это стандарт де-факто (а darcs тяжёлый пережиток прошлого).

> а пока посижу на hg.

Та какая разница, если будут гуглить и там и там найдут. Да и особо полезного кода для сообщества у меня нет)

>> Но у меня вот еще вопрос возник, можно ли заставить лисп печатать по человечески твой вариант, имею ввиду аналог :print-function для структур? Я собственно структуру только из-за него и использовал.

> Неа.

Вообще говоря, можно. Если *print-pretty* t, то можно свой диспатчер на типы вешать:

(defun print-money (s r colon? atsign?)
  ...)

(setq *print-pprint-dispatch* (copy-pprint-dispatch nil))
(set-pprint-dispatch 'money (formatter "~/print-money/") 1)

Да у меня этот pretty-printer в ccl и так непонятно как работает.

В общем как-то так получилось что я написал еще одну либу для денег, тут http://code.google.com/p/cl-money-type/ от тех что я писал выше ее отличает простота кода и его прозрачность, ну и конечно отсутствие вороха фич которыми всеравно непонятно как пользоваться.

Кстати, что это за фича в hg которая не позволяет юзать git?

>Кстати, что это за фича в hg которая не позволяет юзать git?

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

• Не дружит с юникодом. Нельзя одновременно использовать под виндой и под линуксом - без плясок с бубном на виндовой стороне (которые должны быть проведены на всех машинах заранее, до начала использования) кракозяблики в именах файлов гарантированы
• Нет той безопасности, которая есть с гитом. Любой неправильно сделанный rebase в меркуриале фатален для данных, а в гите всегда есть reflog
  
• Бранчи не такие, как в гите. Нельзя отбранчеваться по факту, а надо бранчеваться заранее (т.к. информация о бранче прописана в коммите, а не в метке). Все бранчи глобальные и называются везде одинаково => лишняя головная боль при распределенной разработке (т.к. внешние разработчики не могут выбирать такие имена для бранчей, какие захотят).
  
• Скорость, скорость, еще раз скорость.
• "Легкость" интерфейса позволяет "жонглировать" патчами, изменениями и бранчами, чтобы привести репозиторий в нужный, хороший вид.
  

Ну вот сразу бы так сказали, хотя на своем опыте я ни с одной проблемой из этих пока не столкнулся, небыло условий, но информация к размышлению теперь есть, чего-нибудь следующее попробую сделать под git'ом.