3 ms·

Indeed. Common Lisp is similar with regard to the proliferation of mutation.

by adrianm 12y ago

marijn 12y ago
It in fact takes it to amusing extremes, allowing you to mutate even the strings associated with symbols. (setf (char (symbol-name nil) 1) #\U) (Though I guess that could be taken as being the same thing as doing nonsensical pointer arithmetic in C -- you simply should know better.)
- mbrock 12y ago
  I'd point out that Common Lisp, kind of like Smalltalk, is a highly dynamic environment that has historically been used as an operating system in itself. That's one reason why the system is so mutable—you don't want to have to relaunch it even to modify core functionality.
  - adrianm 12y ago
    I actually don't view mutation in Common Lisp as a downside. I find writing high performance (usually numerical, but sometimes not) code in Clojure to be painfully obtuse compared to Common Lisp, but I love Clojure otherwise. Writing highly optimized code can be quite elegant in Common Lisp, and I appreciate that when the problem at hand calls for it.
- informatimago 12y ago
  Actually, this expression is non-conforming: you must not try to modify the string returned by cl:symbol-name. "non-conforming" means you will get different results in different implementation, perhaps something like a nasal dragon, or perhaps an error signaled, or perhaps some more benign behavior. $ clall -r '(progn (setf (char (symbol-name nil) 1) #\U) (quote nil))' CLISP Attempt to modify a read-only string: "NIL" ECL Detected access to an invalid or protected memory address. Clozure Common Lisp --> #|symbol not found in home package!!|#COMMON-LISP::NUL Armed Bear Common Lisp --> COMMON-LISP::NUL CMU Common Lisp --> COMMON-LISP::NUL SBCL --> COMMON-LISP::NUL Some implementations will gladly and blissfully modify the symbol name, and your program will break because it cannot intern the original name anymore (not the best behavior for an implementation IMO); some implementation will detect the non-conforming access. Worse could have happened (remember, you are on the Internet so you can be located by geoip/gps/wifi, and missiles silos can be hacked by botnets). But otherwise indeed in general, mutable lisp objects are mutable, and you can implement mutating algorithms as well as purely functional algorithm. Foremost, you can have an hybrid approach, using what's best to solve the current problem.

Indeed. Common Lisp is similar with regard to the proliferation of mutation.

by adrianm 12y ago

Indeed. Common Lisp is similar with regard to the proliferation of mutation.

It in fact takes it to amusing extremes, allowing you to mutate even the strings associated with symbols. (setf (char (symbol-name nil) 1) #\U) (Though I guess that could be taken as being the same thing as doing nonsensical pointer arithmetic in C -- you simply should know better.)

mbrock 12y ago
I'd point out that Common Lisp, kind of like Smalltalk, is a highly dynamic environment that has historically been used as an operating system in itself. That's one reason why the system is so mutable—you don't want to have to relaunch it even to modify core functionality.
- adrianm 12y ago
  I actually don't view mutation in Common Lisp as a downside. I find writing high performance (usually numerical, but sometimes not) code in Clojure to be painfully obtuse compared to Common Lisp, but I love Clojure otherwise. Writing highly optimized code can be quite elegant in Common Lisp, and I appreciate that when the problem at hand calls for it.
informatimago 12y ago
Actually, this expression is non-conforming: you must not try to modify the string returned by cl:symbol-name. "non-conforming" means you will get different results in different implementation, perhaps something like a nasal dragon, or perhaps an error signaled, or perhaps some more benign behavior. $ clall -r '(progn (setf (char (symbol-name nil) 1) #\U) (quote nil))' CLISP Attempt to modify a read-only string: "NIL" ECL Detected access to an invalid or protected memory address. Clozure Common Lisp --> #|symbol not found in home package!!|#COMMON-LISP::NUL Armed Bear Common Lisp --> COMMON-LISP::NUL CMU Common Lisp --> COMMON-LISP::NUL SBCL --> COMMON-LISP::NUL Some implementations will gladly and blissfully modify the symbol name, and your program will break because it cannot intern the original name anymore (not the best behavior for an implementation IMO); some implementation will detect the non-conforming access. Worse could have happened (remember, you are on the Internet so you can be located by geoip/gps/wifi, and missiles silos can be hacked by botnets). But otherwise indeed in general, mutable lisp objects are mutable, and you can implement mutating algorithms as well as purely functional algorithm. Foremost, you can have an hybrid approach, using what's best to solve the current problem.