Версия книги сломалась бы, если в качестве аргумента передать атом или неправильный список (пара, которая не является списком - что-то вроде (1 2 . 3)
). (Обратите внимание, что он работает с '()
, конечно - не уверен, считает ли TLS, что это атом, или нет.) Это делает вашу функцию на самом деле более устойчивой, хотя, возможно, лучше названной eqv?
/ equal?
, чем eqlist?
. (Я вижу, equal?
используется в eqan?
для проверки числового равенства, но традиционно это имя присоединяется к универсальной функции проверки равенства значений.)
По сути, ваш eqlist?
работает с аргументами любого типа в предположении, что (1) atom?
способен отличать пары (вещи с car
и cdr
) от непар (это отрицательная версия) из pair?
), (2) eqan?
проверяет равенство атомов, (3) все является либо '()
, либо парой, либо атомом. (Ну, на самом деле '()
- это атом в моих глазах - и Petite Chez Scheme с этим согласен.) Версия книги работает с соответствующими списками (включая '()
), делает подобные предположения и не учитывает возможность появления неправильного списка.
Я не удивлюсь, если позже в книге будет представлена более надежная функция проверки на равенство, но у меня нет ее для проверки. В любом случае, опубликованная вами версия книги eqlist?
выглядит как нечто, предназначенное для иллюстрации основных идей, стоящих за списками, а не как то, что вы на самом деле хотели бы использовать в повседневном программировании. На самом деле, данная версия eqan?
будет нарушена в неограниченной среде, где нужно рассмотреть больше атомарных типов данных, среди которых по меньшей мере строки должны учитываться отдельно, что делает недействительными предположения, перечисленные во втором абзаце выше и ломая обе версии eqlist?
.