3 ms·

> (1) There is nothing in the function name that would indicate the difference between, say, (eq) and (eql) and (equal), any more than you could guess what the

by kgwgk 2y ago

> (1) There is nothing in the function name that would indicate the difference between, say, (eq) and (eql) and (equal), any more than you could guess what the difference between (colorise), (clrise) and (clrs) would be on sight. Lisp seems to love doing this. To me, it just seems like an obvious source of subtle bugs. What alternative would you suggest? Giving paragraph-length names to the functions? Common Lisp already has some of the more descriptive function names around and they can be inconvenient if the function is used often. (By the way, there is something that helps to remember what those functions do: shorter names are correlated with more primitive and restrictive checks.) Having a single function that performs different checks depending on a parameter? If you don’t know which function to use you don’t know which parameter to use either. Removing the ability to perform different kinds of checks entirely?

doctor_eval 2y ago
I think troad is trying to explain how they feel about learning CL and what they've discovered. They aren't criticising CL. Of course naming things over a long period of time is a complex problem, that's why they acknowledged that there is a lot of cruft from the 60s. I've found their comments, and the constructive responses to them, interesting because I am interested in Lisp but have never learned it. What I don't find interesting is seeing troad's observations strongly challenged, as you are doing, as if somehow by sharing their observations, they now owe us detailed solutions as well. It's not cool.
- kgwgk 2y ago
  Fair enough. In fact I agree with the broad point that having functions that do things is a source of bugs and CL is a huge language with less than perfect names. My point is that having less functions that do less things does not obviously reduce the number of bugs in the end if those things still need to be done. Anyway. I see how a logical argument may be out of place if the thread is understood about sharing feelings and not about challenging claims.
pfdietz 2y ago
I'd suggest changing the name from SORT to NSORT, just for consistency and bug avoidance. :) But it's water under the bridge and one can patch this (or, really, any gripe about function names) by suitable package fu, at the cost of making your code less readable to others.
- kazinator 2y ago
  I did exactly that in TXR Lisp, after initially following the Common Lisp naming. In the same change, I also made a function called shuffle nondestructive, and introduced nshuffle. It's a backwards compat breakage, but there is a mechanism in the language which helps with such situations. txr -C 237 or setting the TXR_COMPAT environment variable to 237 or lower will restore the destructive behavior of sort and shuffle. People who don't want to fix their code can deploy that way. I hate compatibility breaking changes, but it was a real thorn in my side how sort is destructive without any indication in its name, in a language where destructive versions of functions should be separately named. Now the thing is that sort is not required to be destructive. It is allowed to be. Therefore code written to the language spec will not break if sort becomes pure. But we have to worry about breaking all programs though, not just programs written to the spec. (Unless we are GCC maintainers; different rules apply.) You can't just say, "Oh, programs that call sort on a vector and ignore the return value, expecting the vector to be sorted, are just nonportable junk; let them break."
  - pfdietz 2y ago
    In general, the "N" versions of functions in the standard say they "maybe" or "might" modify arguments. SORT and NSORT should have been like this, but IIRC SORT was taken from Interlisp, where it was destructive.
- kgwgk 2y ago
  I agree that there are some inconsistencies in the naming of functions and parameters like destructive/non-destructive variants and predicates among other things. Also strange names like car and cdr (which on the other hand allow for cadr et al.). However, even though they can be confusing, I wouldn’t put the equality functions in the same bag.

by kgwgk 2y ago

doctor_eval 2y ago

I think troad is trying to explain how they feel about learning CL and what they've discovered. They aren't criticising CL. Of course naming things over a long period of time is a complex problem, that's why they acknowledged that there is a lot of cruft from the 60s. I've found their comments, and the constructive responses to them, interesting because I am interested in Lisp but have never learned it. What I don't find interesting is seeing troad's observations strongly challenged, as you are doing, as if somehow by sharing their observations, they now owe us detailed solutions as well. It's not cool.

kgwgk 2y ago
Fair enough. In fact I agree with the broad point that having functions that do things is a source of bugs and CL is a huge language with less than perfect names. My point is that having less functions that do less things does not obviously reduce the number of bugs in the end if those things still need to be done. Anyway. I see how a logical argument may be out of place if the thread is understood about sharing feelings and not about challenging claims.

pfdietz 2y ago

I'd suggest changing the name from SORT to NSORT, just for consistency and bug avoidance. :) But it's water under the bridge and one can patch this (or, really, any gripe about function names) by suitable package fu, at the cost of making your code less readable to others.

kazinator 2y ago
I did exactly that in TXR Lisp, after initially following the Common Lisp naming. In the same change, I also made a function called shuffle nondestructive, and introduced nshuffle. It's a backwards compat breakage, but there is a mechanism in the language which helps with such situations. txr -C 237 or setting the TXR_COMPAT environment variable to 237 or lower will restore the destructive behavior of sort and shuffle. People who don't want to fix their code can deploy that way. I hate compatibility breaking changes, but it was a real thorn in my side how sort is destructive without any indication in its name, in a language where destructive versions of functions should be separately named. Now the thing is that sort is not required to be destructive. It is allowed to be. Therefore code written to the language spec will not break if sort becomes pure. But we have to worry about breaking all programs though, not just programs written to the spec. (Unless we are GCC maintainers; different rules apply.) You can't just say, "Oh, programs that call sort on a vector and ignore the return value, expecting the vector to be sorted, are just nonportable junk; let them break."
- pfdietz 2y ago
  In general, the "N" versions of functions in the standard say they "maybe" or "might" modify arguments. SORT and NSORT should have been like this, but IIRC SORT was taken from Interlisp, where it was destructive.
kgwgk 2y ago
I agree that there are some inconsistencies in the naming of functions and parameters like destructive/non-destructive variants and predicates among other things. Also strange names like car and cdr (which on the other hand allow for cadr et al.). However, even though they can be confusing, I wouldn’t put the equality functions in the same bag.