Assoc

Why does assoc return both a key and a value? Is there a strong reason for that or it's just a historical atavism?

>>1
`> inferring that a function can return more than one valuen

>>1
Because CL is bloated with legacy. It has assoc, hashes, plists, when it would be nice to have finger-tree for everything.

>>3
Because CL is bloated with legacy
Yes that's true, too bad we don't really have anything better. Scheme chose the other extreme and is too austere to be practically useful. Hence dozens of SRFIs and incompatible across implementations libraries and language extensions. All in all I think CL is a good standard, mostly a well thought-out and with lots of useful functionality. It just needs to be seriously cleaned up and adapted to the modern situation (sockets, threads etc).

>>1
Returning multiple values is not unusual in CL, it's actually pretty useful and can lead to simpler code, however in this case it doesn't return multiple values, it returns a CONS as found in your alist. The reason for this is that you can specify key and test keyword arguments which means your key may be different from the item you're searching for (let's say you're doing a case insensitive search for a string, the value your searched for could be "string", but item it found could very well be "STRING" or "String" and so on. Just because you don't know the reasoning behind some choices in CL doesn't mean it's always for historical reasons. Some thing are, but I'd suggest you consult the documentation or people versed in the history of CL (see comp.lang.lisp) if you want to know the reason something is like it is (if it doesn't make sense to you).
>>2
CL can return multiple values and it's a very useful feature, especially as far as efficiency is concerned(instead of passing consed up lists each time you want to return multiple values), but assoc (what OP asked about) doesn't return multiple values, it returns the item from the alist that it found.

>>3
You can have some averagely-efficient tree to implement any generic container you want. There's some such implementations using CLOS (see libraries), however while such things are averagely efficient, when you know more exactly what you want, those specific underlying implementations CL provides will be more efficient. It may be similar to premature optimization, but it's nowhere near as bad as what you have to do in C - at least in CL you have the option to pick either something efficient, but specific to your task or something averagely performing, but generic enough. I could go on about this, but I think you'd enjoy 300+ post threads on c.l.l arguing about this more.

>>5
>CL can return multiple values and it's a very useful feature, especially as far as efficiency is concerned
Redundant: you can return values as list. All these "features" make CL very hard for newbies and experts alike: you've dilemmas everywhere.

As said Alan Perlis: "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures."

And mutiple-value-form is definetely a new structure, incompatible with normal lists and your 100 functions.

>>7
Never been a problem for me. Returning lists is quite inefficient and does not embody the purpose of the code.

>>8
It's not a structure, even if it can be. In most implementations multiple values are returned as different registers, which is much faster than multiple memory allocations and assigning pointers which is what building up a list is.

>>8
"It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures."
(-︢  ̱-︡   )

How about one function operating on 100 data structures?

>>12
Reminds of Windows message handler.

>>9
>Returning lists is quite inefficient and does not embody the purpose of the code.
It could be optimized during runtime automatically.

>>10
>It's not a structure, even if it can be. In most implementations multiple values are returned as different registers,
It's a n-tuple that maps to stack/registers. C/C++ also supports returning structures and optimizes them to regs.