Цитата

---

(list? `(1 . 2))

---

SRFI-1

---

proper-list? x -> boolean
Returns true iff x is a proper list -- a finite, nil-terminated list.

More carefully: The empty list is a proper list. A pair whose cdr is a proper list is also a proper list:

<proper-list> ::= () (Empty proper list)
| (cons <x> <proper-list>) (Proper-list pair)

Note that this definition rules out circular lists. This function is required to detect this case and return false.

Nil-terminated lists are called "proper" lists by R5RS and Common Lisp. The opposite of proper is improper.

R5RS binds this function to the variable list?.

---

В схеме list? используется только для проверки на proper-list. Т.е. list? - это сокращение для proper-list? (SRFI-1). А в лиспе используется проверка на proper-list и improper-list, т.е. на любой вид списка.

Не понял, при чем тут парсинг. Понятно, что так исторически сложилось, но по факту improper list не являются списками. То есть они improper list, но не list.

Цитата

---

Не понял, при чем тут парсинг.

---

А в чем проблема с improper-list? Тем более, что в случае dotted-list экономия в одну cons. Или может философия не позволяет?

Цитата

---

по определению списка как АТД.

---

По какому такому определению? Я же указал ранее, что improper-list полностью соответствует определению (приведенному выше).

Цитата

---

в чем?

---

Решили ответить по-еврейски? Ну, так я первый спросил.

Цитата

---

Про проблемы с improper list и парснигом видимо кто-то другой говорил.

---

Ну, так у вас есть проблемы с парснигом или нет? Или это секрет?

Цитата

---

это не лисповое определение, а вообще общепринятое определение списков.

---

Вне лиспа под nil обычно подразумевают null, что несколько меняет дело.
В общем-то любой лиспер знает, что proper-list завершается атомом nil, dotted-list - любым атомом, а circular-list - ссылкой на начало.

Цитата

---

Не стоит этой сущности давать еще и третье название (список)

---

Сами названия proper и improper уже говорят за себя. proper - истинный (общепринятый). А improper - ложный (мнимый).
И так так эти понятия являются общепринятыми среди лисперов, то не стоит пререкаться и искать альтернативы.

Цитата

---

я же говорю - у меня нету никаких проблем с парсингом.

---

А так и должно быть, ведь парсить improper-list, как я уже сказал ранее, довольно просто.

Цитата

---

и противоречат общепринятым _в принципе_

---

Я подозреваю, что текущие "общепринятые" закрепились гораздо позже, нежели те сформировались в среде лисперов.

Цитата

---

вроде никто и не спорил

---

Ну, мне так не показалось

Цитата

---

ну так были еще более ранние общепринятые, если уж на то пошло. и там любой граф точно не был списком

---

Хотя данный вопрос довольно часто подымется на англоязычных форумах, но тем не менее лисперы как использовали improper-list, так их и используют. Наверное, в них есть что-то привлекательное

Цитата

---

gihar :
Так как тема зашла в тупік, поэтому снова вніманіе на проблему топікстартера.

Конечно, никакого другого Лиспа Вы топикстартер не придумали, потому как факторы скорости и размера занимаемой памяти идеологию лиспа не волнуют по-умолчанию.

---

Придумал. Так же как Scheme и CL это разные Лиспы, так и реализация этого диалекта была бы новым Лиспом.

Цитата

---

gihar :
Собственно, Ваш вопрос это отраженіе прямого кріка Вашей пытливой душі: "Народ я так і не понял нафіга нужны cons-ячейки?

І вправду, нафіга нужны эты консы?

Проблемка то глобальная! Философская!

В каком типе кодерского действия раскрывается сакрыльный смысл конса?

)

---

В этом топике ясно было сформулировано зачем нужны именно cons-ячейки и с тем, что они по праву занимают свое место я так же явно согласился.

Цитата

---

Kergan :
Да нет, вы придумали не новый лисп, а новую реализацию лиспа. То есть то что вы описали - может быть тем же CL или Scheme.

---

Только программы написанные на CL не будут на нем исполняться и он не будет соответствовать стандарту, а так да -- тот же CL.

Цитата

---

Kergan :
с чего вдруг? и стандарту будет соответствовать и программы будут исполняться. Стандарт CL не регламентирует конкретное представление cons-ячеек.

---

Да, действительно будет соответствовать стандарту.

чтобы знать зачем консы нужно погрузіться в атмосферу программірованія 70-80, нужно вспомніть как относілся к орграфам Дейкстра. Фантастіческіе ідеі по развітію іскусственного інтеллекта. Консы это программное отраженіе ідеі орграфа, где сушность имеет "имя + вес", это может быть даже "имя + фамилия" или "маршрут + цена" билета, а если обобщить полностью то "значеніе + тэг". Тэг-Алгоритмы, основанные на консах, не могут быть быстрыми для выполнения тривиальных задач. С другой стороны Дейкстре повезло со своим алгоритмом поиска кратчайшего пути, иначе не было бы ни одного доказательства в пользу ПАРЫ. Но одного этого алогоритма хватает чтобы вынести мозг. Идея CONS-алгоритма на манипуляции тегами, когда меняя один всего лишь тэг тот что CDR, не меняя функціональной базы (функцій і процедур) заставлять программу пріспосабліваться к новым условіям какбы іммітіруя мышленіе человека.

Еслі із Ліспа убрать КОНСЫ, то на выходе получім - обычное скучное Г. Это тоже самое, что із псіхікі человека убрать веру в сказку бесконечності міров вселенной, получім на выходе - особый сорт людей (ОСЛ).

Так мыслі вслух:
О скорості выполненія программ: простая аналогія: Одін пользуется скоростным автомобілем чтобы добраться за 2 часа до работы, а второй жівет рядом с местом работы і тратіт 5 мінут без авто. Как і в жізні в программинге, все решает правільная структурізація. ), і не оптімізація как некоторые могут подумать. Оптімізація это насіліе над собой ілі над программой в целях сократіть іздержкі времені і денег, вытекает в итоге в созданіе жесткого режіма ілі программной сістемы, где случайноге паденіе одного элемента вызывает лавинообразное паденіе других - "эффект доміно".
Эффект Структурізаціі это своего рода мудрость, качественный взгляд на предмет.

Очевидно, что Лисп предлагает способ структуризироваться - "Хитрыми Консами".
Однако, король промышленного программірованія - "Ассоціатівный он же Хэш Массів".

Цитата

---

metadeus :
почему в качестве основного типа данных используются cons-ячейки?

---

1. CONS-ячейки проще реализовать.
2. Они проще теоретически: разделяй и властвуй.

Цитата

---

На мой взгляд более правильным было бы использовать массив

---

Массив не поддерживает O(1) добавление и взятие хвоста.
Удобней уж закладочные catenable double ended queues с path-copying и закладками на концах (aka finger trees). Они дают O(log N) доступ/катенцию и O(1) доступ к концам.

Но cons-ячейки концептуально проще. Более того, списки должны присутствовать ещё на этапе bootstrap-а, когда неготовы сборщик мусора и компилятор. Т.е. разрвботчику компилятора приходится их ручками вводить. А Finger Trees и даже простые массивы - сложные структуры, требующие тонну бухгалтерии (для массива требуется тип элементов, размер и указатель).

Цитата

---

Какие я вижу преимущества:
1. -1 тип данных -- cons-ячейка. Проще в реализации, чище в теории.
2. Не нужно вносить иметь отдельный тип данных "массив", когда весь AST представлен в списке.
3. Массив имеет константную сложность для выборки элемента по индексу, таким образом (nth 3 '(0 1 2 3)) будет работать быстрее.
4. Массив занимает меньше места, чем список на cons-ячейках.
5. Массив определенной длины быстрее выделить в памяти, чем список на cons-ячейках.
6. Массив с константным временем доступа на cons-ячейках реализовать сложно/ресурсовемко/невозможно, поэтому в лиспах делают массив отдельным типом встроенным в Лисп-машину, реализовать же cons-ячейку на массивах тривиально.

Жду ваших комментариев почему я "***баёп" и мой Лисп "не нужын". Спасибо!

---

У вас premature-optimization. Большинcтво cons-списков и так исчезает после компиляции. А скорость исполнения макросов была приемлемой даже на железе 60х годов.