3 ms·
I saw a fun debugging issue the other day on r/lisp that almost made me want to walk away from lisp for good. You have a function (defun my-val () "a string")
by blacktriangle 6y ago
I saw a fun debugging issue the other day on r/lisp that almost made me want to walk away from lisp for good.
You have a function
(defun my-val () "a string")
Referentially transparent, easy to reason about right? Wrong. Lisp strings are mutable, and everything is a reference. So if you do something like this
(replace (my-val) "b" :start1 0 :end1 1)
(my-val) => "b string"
I appreciate that CL doesn't force everything to be immutable, but it seems like at least strings would benefit from being treated as immutable values.
- abhinav22 6y agoInteresting example. Yes, it’s not a perfect language by any means :-) Some things are better in Lisp, some things are better in other languages as well for sure!
- kagevf 6y agoI remember that ... it was pretty surprising! I thought I could do (string "a string") to prevent it, but that didn't work. (concatenate 'string "a string") worked, though ...
- dreamcompiler 6y agoDestructive modification of literal objects is one of those things you're not supposed to do because the consequences are undefined [0]. Some CL implementations might let you get away with it; others might not. I agree that it would be better if immutability was required for literals. [0] http://www.lispworks.com/documentation/HyperSpec/Body/03_abac.htm http://www.lispworks.com/documentation/HyperSpec/Body/03_aba...
- blacktriangle 6y agoNice link. I'd be happy if an implementation just turned that into a compiler error. I can see use cases for reaching in and mutating like that, but also seems like dynamic scope is a better solution for when you want that kind of action at a distance.