наверняка можно получить исходный список более однородной структурой.В моем случае структура определяется данными, извлекаемыми из помещения (space или zone) для формирования различных ведомостей и спецификаций архитектурно-строительных чертежей.
Вот только пока не смог добавить в эту функцию второй аргумент, чтобы исходный список обрабатывался не только ф-цией 1+, а любой произвольной, заданной вторым аргументом.Ну по "стандартам лиспа" только не вторым аргументом, а первым (второй список):
А, может, выгоднее будет создать ассоциативный список по типу
Код - Auto/Visual Lisp: [Выделить]
'(("space" ("Тип помещения" <Перечисление площадей>)
("Тип помещения" <Перечисление площадей>)
...
)
("zone" ("Тип зоны / группы помещений" <Перечисление площадей>)
("Тип зоны / группы помещений" <Перечисление площадей>)
...
)
)
И обрабатывать уже отдельные типы объектов?
#9 lambda lambda ...
мне показалось проще чем
#12 mapcar function lambda ... apply function
если предположить, что проще это лучше то выбор за Димой #9
но в качестве ответа к вопросу темы больше подходит #12 от gomer
В чем состоит особенность применения ATOM в последней ф-ции в отличии от LISTP во всех предыдущих?Проверяется тип передаваемого аргумента - атом или список.
В каких случаях целесообразнее использовать mapcar при обработке структуризированных списков если вполне можно обходиться без него?Да практически во всех. В автолиспе рекурсия очень "слабая" - нет "хвостовой" оптимизации, а в "стеке" хранит максимум на 20 тысяч "уровней" - то есть это только для самой простой "одноуровневой" рекурсивной структуры - например для создания списка - для более сложной в соответствующее кол-во раз меньше. Автолисп написан очень давно, когда байты и машинные такты еще приходилось считать - и задачи на него возлагались в более приземленном виде, а требование к "качеству" кода были выше. Если есть "большая" задача (и тут самое сложное заранее понять в каком измерении она может вылезти за разумные рамки автолиспа) автолиспом ее как правило реализовать-таки можно - но не эффективно - на него очень хорошо ложатся задачи до определенного уровня (быстро, просто и "красиво") - а сверх него - обрастает костылями сводя на нет все свои сильные стороны - а их не мало. Практически все "встроенные" функции написаны не на автолиспе (как это принято делать в "классических" лиспах), а являются менее высокоуровневыми скомпилированными структурами (хотя на момент создания автолиспа уже были эффективные трансляторы с лиспа - производительность которых не уступала, но автодеск пошел по более простому и менее затратному, но в конечном счете тупиковому пути).
В каких случаях целесообразнее использовать mapcar при обработке структуризированных списков если вполне можно обходиться без него?Да практически во всех...
(
(набор1 характеристика3)
(набор1 характеристика12)
(
(набор2 характеристика1)
(набор2 характеристика3)
(набор3 характеристика1)
)
...
)
Если придираться - то проверка в строке 14 частично избыточна с строкой 9 (если ((car)lst) список - то он точно не строка*) - да так в общем можно делать - но если идет процесс увеличения "% понимания", то желательно, хотя-бы в целях самообразования подумать как это лучше исправить.