4 ms·
Quite confused. Two examples: > It turns out there is very little code that would break if Emacs strings became immutable Which means that very little Clojure
by cronjobber 9y ago
Quite confused. Two examples:
> It turns out there is very little code that would break if Emacs strings became immutable
Which means that very little Clojure code would break if they just went ahead and used Emacs strings.
> Common Lisp fans claim that lisp-2s have first-class functions, but the way they are kept separate from other first-class values in their own namespace ghetto brings to mind claims of "separate but equal"—at best it is Jim Crow functional programming.
Jim Crow functional programming?? The virtue signalling is strong in this one. He's wrong on the facts, too.
A Lisp-2 doesn't keep the function inside the ghetto, it keeps everyone else out. Functions can be everywhere, but a non-function can't be the value of a function binding. Function's aren't second class in this system, they're royal class.
- db48x 9y agoHe means that Emacs Lisp code wouldn't break much if strings were made to be immutable; you don't generally mutate strings. (Buffers, on the other hand, are mutated all the time.) I would suspect that the converse is also true though; Clojure code probably doesn't often rely on strings sharing storage, so making them mutable might not have a huge effect. I've less experience with Clojure than with Elisp, though, so I might well be wrong. As for the latter, it does occasionally feel like functions aren't truly first-class in a lisp-2 because you have to jump through hoops to pass them along as an argument (funcall, #'foo syntax, etc). In most lisps passing functions as arguments is just as common as "calling" non-function values is in Clojure. Anyway, I suspect that the "Jim Crow" dig was hyperbole, not intentional virtue signalling. :P
- lispm 9y ago> does occasionally feel like functions aren't truly first-class in a lisp-2 The definition of 'first class functions' is not a feeling, but three capabilities: CL-USER 9 > (let ((sin-fn (function sin))) (list ; 1) passing functions as arguments to other functions (mapcar sin-fn '(1 2 3 4)) ; 2) returning them as the values from other functions ((lambda () sin-fn)) ; 3) and assigning them to variables or storing them in data structures (let ((v #(1 2 3))) (setf (aref v 1) sin-fn) v))) ((0.84147096 0.9092974 0.14112 -0.7568025) ; 1) #<Function SIN 410007BC14> ; 2) #(1 #<Function SIN 410007BC14> 3)) ; 3) As you can see, functions are first-class values in Common Lisp. > In most lisps passing functions as arguments is just as common as "calling" non-function values is in Clojure Including Lisp-2s. Passing functions is completely normal and widely used in Common Lisp. The Common Lisp standard has literally zillions of functions where you pass one or more functions in. Common Lisp also can make CLOS objects callable.
- db48x 9y agoYou've made my point for me. The very fact that you must write (function sin), or #'sin, or use funcall is a way that it treats functions differently than normal values. Since it requires some amount of extra though and/or typing, this often seen as a bad thing. Compare Scheme, Clojure, or other lisp-1s where if you want to pass the sin function to someone, you just say sin. That whole outer let vanishes in those languages, and the result is much simpler. And just as we both agree that in Common Lisp passing functions in as arguments is very common, so in Clojure is "calling" a vector on a number to index into it, or "calling" a symbol to use it as an index into a alist or hash table, etc. Not only do you not have to type anything extra, you can treat all values as callable.
- lispm 9y ago> The very fact that you must write (function sin), or #'sin, or use funcall is a way that it treats functions differently than normal values. Look closer. I have not used FUNCTION in 1), 2) or 3). Common Lisp does not treat functions different from other values. They are first class values. These are the three operations which define whether functions are first class values: ( https://en.wikipedia.org/wiki/First-class_function https://en.wikipedia.org/wiki/First-class_function ) : 1) passing a function 2) returning a function 3) assigning them to variables or storing them in data structures None of that requires anything special for functions in Common Lisp. What you need to do in Common Lisp, is to use FUNCTION to get a function from a lexical name and you need to call such a function via FUNCALL, but that has nothing to do with the requirements for a 'first class datatype', which is defined by the three requirements above (passing, returning, assigning).
- db48x 9y ago> What you need to do in Common Lisp, is to use FUNCTION to get a function from a > lexical name and you need to call such a function via FUNCALL, but that has nothing > to do with the requirements for a 'first class datatype', which is defined by the > three requirements above (passing, returning, assigning). And I'm saying that in practice, regardless of any technical definitions you'll find in a textbook, this need to treat functions specially is exactly what makes people who learn Common Lisp wonder why people say that functions are first class values. You don't have to look up the value of a variable by writing (variable foo), but you do have to use (function foo). Clojure goes one step further and lets you treat non-functions as if they were functions, by using them in the function positions of expressions.
- cronjobber 9y ago> you don't generally mutate strings If strings in Emacs are mutated so rarely that making them immutable would cause almost no breakage, it logically follows that strings in Emacs are mutated so rarely that using them from Clojure as if they were immutable would cause almost no problem either.
- db48x 9y agoExcept that the resulting breakage would be _surprising_. It would be especially surprising to Clojure developers, who are are even more likely to want to rely on immutable data structures.
- wcummings 9y ago>Jim Crow functional programming What a gross metaphor, feels totally out of place.