Post
In #CommonLisp, `=` takes arbitrary numbers of args, but `eq` takes exactly two.
In #Scheme `=` takes arbitrary numbers of args, and `eq?` also takes arbitrary numbers of args.
In #Logo, `equalp` takes exactly two args, and I don't think there's an equivalent of `eq`.
In PSL, and in Lisp 1.5, both `equal` and `eq` take exactly two args.
#Clojure doesn't have `eq`, but `=` takes arbitrary numbers of args.
Do you see any reason that `eq` should take only two args?
@simon_brooke In Common Lisp, eq, eql, equal and equalp all take exactly two arguments. The functions <, <=, =, >=, > are for numbers only. It's good to be able to chain multiple arguments with <, <=, >= and >, so I guess = has that as well for symmetry. Don't compare this to languages where = can be used for non-numeric arguments.
@pascal_costanza Why do you think it is beneficial that eq, equal, and equalp should take only two arguments?
As far as I can see from implementing both strategies, there's no performance penalty to having an n-ary implementation even when only two args are passed, and although the occasions when you would want to apply `equal` to a collection of several hundred objects may be rare, it's nice to be able to do it.
@simon_brooke there is an easy way around this, e.g.
(reduce #'eq '(t t t t)) -> t
@hajovonta Yes, thank you, but I know this. I'm trying to decide what semantics to adopt for my own #Lisp, which is neither common nor standard.
@simon_brooke You're not changing `=` to `=?` ? 😜
@sigue There would be a consistency to that, since it is a predicate, but no, I don't think so.
Also, in #CommonLisp, `=` with one arg returns `t`, but `=` with no args errors. `eq` with one arg errors.
In #Scheme both `=` and `eq?` return `t` for either one or zero args.
Again, I feel Scheme has this right. Do you concur?
@simon_brooke I do not know much about language construction. So, I am just thinking this through via reasoning.
It seems to me that perhaps the only reason that one would want to replicate the constructions and inconsistencies of Common Lisp would be if they expect that a large part of the people that will be using their system come mostly from the Common Lisp world, and that the language creator wishes to make the transition for users of their system to be as seamless as possible for Common Lisp coders.
But if that is not the case, then I think it would make sense to try to create a system so that forms are as predictable and intuitive and consistent in their functioning as possible.
I think that avoiding assorted gotchas for eventual users is what language creators should aim for.
Remembering piecewise behavior (ex., in this situation, it works this way, but in that, however …) is unnecessary mental overhead, IMO.
@jotaemei exactly. This is Jon Postel's 'be liberal in what you accept' dictum. Someone coming from an environment in which these functions are binary may never discover that in this new environment they're n-ary, but actually that doesn't matter.
Those who expect them to be n-ary should not have to trip up over the fact that now they're binary.
I mean, I *am* trying to implement the best #Lisp I can, but it's also true that my ideas of what makes a good Lisp are certainly not mainstream.
