Like what? The only thing that bugs me is (file-position s n) instead of (setf (file-position s) n)
Take a look at:
Code: Select all
(cons item collection) ; fixed :)
(gethash item collection)
(elt collection item)
(nth item collection)
(aref collection items)
(assoc items collection)
(getf collection item)
I somewhat agree and disagree with you.
I agree that nth
(which wasn't mentioned) and also gethash
are reversed. I believe assoc
isn't reversed because it does not belong to this group, but to the same group as find
, ... assoc
is about finding some item by walking through the list, not fetching something from a predetermined position.
Code: Select all
(assoc item collection) ~ (find item collection :key #'car)
The same could be argued about gethash
, but that is not my opinion. By the way, the thing that most confuses me is sort
(and, of course, stable-sort
). They should be in this "walking through" group, and as such it should be called like (sort predicate sequence)
instead of (sort sequence predicate)
Since I never use nth
(in these cases I either use an array or destructuring-bind
...), I don't care about it being reversed
, it shouldn't be in this group in the first place, since it constructs, not fetches, and it is not reversed for a logical reason (it is (cons first rest)
because the first element comes before the rest).
And a general rule about doubts in the sequence of arguments (and what arguments are accepted): use slime and look at emacs' status bar - it never fails
And there was this evil little joke stuck in 'loop':
Code: Select all
(loop for k being the hash-keys of h using (hash-value v)
It's maybe funny the first 100 times you type it out. (Not common enough to dedicate an emacs hotkey, not rare enough to be ignored... Maybe I should've written loop-mode.)
Hum... No arguments here
That is one of the reasons why I like Iterate
better than loop. In any case, there comes maphash
for the salvation
Well, not complete salvation, I agree
but traversing hashtables is mostly useful for copying hashtables and other rare ocasions, and maphash deals with 99% of the cases very nicely.
Harleqin wrote: tayssir wrote:
A wonderful example where CL's inconsistency can trip a user up, causing a typo on the most basic operator of the bunch.
The art of the meta-example...
I think that this just shows that you have not understood CONS.
Well said :p
Some of those are easily justifiable (e.g. GETF gets a place, GETHASH gets a value associcated with a hash) while others are not. It's not as incoherent as you made it to look here.
I suspect that the fact that some have easy justifications -- while others don't -- is precisely why it's 'inconsistent.' That's why we speak of inconsistency rather than (say) randomness or consistency.
I believe this is about disagreement. Disagreement sucks, there isn't much we can do about it.
CL sure does have its inconsistencies (just look at the map--- functions (how they are named) and you'll see a mess). But isn't it true in all languages? And also between different libraries - each library uses its creator's own conventions, and each one's conventions are different from each other. I believe this is a very small issue with CL, the smaller one, it is just a matter of getting used to it. The lack of standardization of modern tools (threads, sockets...), as I already mentioned, is much worse than this... Well, nothing that some compat libs like bordeaux-threads and usocket (or other socket lib) can't take care of
but it would be much nicer and consistent if they were standardized, then you could rely on it being there always.