4 ms·

I would love to hear more on the security challenges and debugging issues, if you have time. It’s not used as much in industry, so any insights are really very

I would love to hear more on the security challenges and debugging issues, if you have time. It’s not used as much in industry, so any insights are really very valuable. Also so cool that you worked in AI! That’s my dream field :)

blacktriangle 5y 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 5y ago
  Interesting 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 5y ago
  I 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 5y ago
  Destructive 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 5y ago
    Nice 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.

blacktriangle 5y 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 5y ago
Interesting 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 5y ago
I 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 5y ago
Destructive 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 5y ago
  Nice 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.