LINUX.ORG.RU

2den73 (Lisp Hierarchical Packages)


0

0

Я обдумывал (да, я медленно думаю) твои негодования на тему лиспа и
ООП в нем. Вобщем, привязывать ф-ции к классу в CLOS так или иначе
бессмысленно, ибо непонятно к кому привязывать - диспатч по нескольким
параметрам, и к кому вязать? Конгруэнтность ламбда листов, вроде бы
грустная штука, но только если у нас все ф-ции валятся в один
нэймспейс. А если сущности разные по разным неймспейсам сложены, то
все вроде ничего. И всех нужд для удобства, только вложенные
нэймспейсы и никнеймы для них. Всвязи с этим вопросы:
1) Есть ли претензии к вышеизложенным домыслам?
2) Ты вот эту ссылку читал?
http://www.franz.com/support/tech_corner/hierpackuser.lhtml
Чем не решение проблем?

★★★

Жаль, relative-package-names в sbcl нет...

mv ★★★★★
()

> А если сущности разные по разным неймспейсам сложены, то все вроде ничего.

Попробуй привести пример кода. По-моему, фигня получается всё равно. В С++ и жабе тип объекта указывается один раз, и после этого ясно, что любой идентификатор после "." относится к этому типу. В лиспе так не получится до тех пор, пока не будет введена статическая типизация.

Хотя иерархические пакеты полезны сами по себе. Я работал над этим (и до сих пор работаю). Пока что релиза нет, но я уже включил эту библиотеку в свой рабочий код.

http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/2c34834672...

Более полезным здесь кажется не то, что работают иерархические пакеты,а то,что можно локально (в рамках пакета) назначить короткие псевдонимы другим пакетам, а также писать package:(function arg1 arg2), так, что всё внутри круглых скобок будет считано в контексте пакета package. Старожилы c.l.l. говорят, что такой синтаксис когда-то в некоторых диалектах лиспа был, но как и многие другие хорошие вещи, не был включён в стандарт.

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

Хотя, в любом случае, для меня основная проблема лиспа - это библиотеки. Редкую библиотеку мне не приходилось патчить, перед тем как я мог начать с ней работать. При этом, поражает убожество многих библиотек. Например, я взял библиотеку Local-time и я до сих пор не умею прибавить к дате энное количество дней, хотя мне и её пришлось патчить, чтобы хотя бы (now) возвращало правильный результат, а не 2099 год. В питоне я разобрался с вопросом прибавления дней к дате примерно за три минуты. Конечно, патчить в лиспе легко из-за его динамической природы. Но я не четырнадцатирукий Бог. Вроде бы есть ещё одна библиотека по вопросу дат - порт перловой библиотеки. Может быть, она лучше, но почему-то в живых современных проектах, с которыми я сталкивался, используется local-time.

Это я, в общем, говорю к тому, что (* производительность-труда число-фанатов-лиспа) даёт все же низкую цифру. Наверное, интересно играть в лисп для общего развития (некоторые его идеи всё же пока нигде больше не замечены в таком же полном и совершенном виде). Но не стоит вкладывать в него серьёзные силы, если Вы не готовы к постоянной борьбе с библиотеками. Во всяком случае, такова ситуация на сегодня.

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

> Более полезным здесь кажется не то, что работают иерархические пакеты,а то,что можно локально (в рамках пакета) назначить короткие псевдонимы другим пакетам, а также писать package:(function arg1 arg2), так, что всё внутри круглых скобок будет считано в контексте пакета package. Старожилы c.l.l. говорят, что такой синтаксис когда-то в некоторых диалектах лиспа был, но как и многие другие хорошие вещи, не был включён в стандарт.

А вот это я хочу :) Репозитарий делали?

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

> А вот это я хочу :) Репозитарий делали?
Нет, пока есть только tgz на файлообменнике. Ээээ. Я уже почти чувствую себя обязанным открыть учётную запись на common-lisp.net :)
Но ещё не настолько, чтобы это сделать...

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

>В С++ и жабе тип объекта указывается один раз, и после этого ясно, что
>любой идентификатор после "." относится к этому типу. В лиспе так не

>получится до тех пор, пока не будет введена статическая типизация.


Не понимаю как здесь статическая типизация поможет?
Точка здесь не выйдет однозначно ибо диспатч по многим классам.
Разьве что (classInstance1,classInstance2).(param1,param2), но это
неудобно и визуально задницу с татуировкой напоминает.


>Более полезным здесь кажется не то, что работают иерархические

>пакеты,а то,что можно локально (в рамках пакета) назначить короткие

>псевдонимы другим пакетам, а также писать package:(function arg1 >arg2), так, что всё внутри круглых скобок будет считано в контексте

>пакета package.

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

>в некоторых диалектах лиспа был, но как и многие другие хорошие

> вещи, не был включён в стандарт.


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


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

>Не понимаю как здесь статическая типизация поможет?
>Точка здесь не выйдет однозначно ибо диспатч по многим классам.

>Разьве что (classInstance1,classInstance2).(param1,param2),


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

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

Не вижу глобальной разницы явно передавать this или не явно.
Просто неясно почему первый... Да и вообще не очевидно порой,
к кому должен относиться метод диспатченный относительно 2-х
разных параметров. И вобщем-то табличка нагляднее показывает.
А чем список аргументов в ф-ции не координаты в табличке.
Мне просто кажется что идея мультидиспатча, как то логически
стройнее. Единственный минус динамики, а не статики - это то,
что не сделаешь автодополнение вариантов ф-ций для объекта.
Но это скорее к ide вопрос.

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

> Не вижу глобальной разницы явно передавать this или не явно
Не хочу это обсуждать - уже обсудили не однажды.

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

>Хотя, в любом случае, для меня основная проблема лиспа - это библиотеки. Редкую библиотеку мне не приходилось патчить, перед тем как я мог начать с ней работать. При этом, поражает убожество многих библиотек. Например, я взял библиотеку Local-time и я до сих пор не умею прибавить к дате энное количество дней, хотя мне и её пришлось патчить, чтобы хотя бы (now) возвращало правильный результат, а не 2099 год.

Не умеешь, фигли на зеркало пенять! А вообще, хочешь найду убогую библиотеку на Java или на другом языке ? Доже бой! Чел пишет на Лиспе и непрерывно его обсирает, нет чтобы задуматься, а может быть у него руки кривы ?

start-lisp
()

А чем плохо:

(defclass foo () ())
(defclass bar () ())

(defgeneric add (object &key))
(defmethod add ((object foo) &key (x 0))
  (1+ x))
(defmethod add ((object bar) &key (a 0) (b 0))
  (+ a b))

den73 проигнорировал этот ответ guest-3484-2009 в другом топике.

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