4 ms·

Is Lisp opinionated about side-effects? Maybe Clojure is, but have you looked at Common Lisp or Emacs? I can't think of a less-opinionated-about-side-effects ap

• kazinator 7y ago
  Lisp is opinionated about side effects like this. * In the absence of language extensions, you don't have a pointer type that can be incremented all over the place and dereferenced. You don't just mutate memory willy nilly. * In relation to the above point, (in the absence of a language extension like "locatives") there is no address-of operator; we can't pass the address of a variable somewhere to have it changed. This can be simulated with a lexical closure, whereby we provide the function to do perform the change, which is called from somewhere. "Use lexical closures as thunks if you want var parameters" is quite opinionated. * All mutation takes place through data-structure-specific functions (like rplaca for mutating the car of a cons cell), or dedicated special forms (like setq for mutating a variable). The use of generalized places like (incf (car x)) compiles into type-safe function calls. On one particular Lisp, CLISP, that looks like: 1> (macroexpand '(incf (car x))) (LET* ((#:TEMP-3341 X) (#:NEW-3340 (+ (CAR #:TEMP-3341) 1))) (SYSTEM::%RPLACA #:TEMP-3341 #:NEW-3340)) there is no idea there of calculating some effective address and just clobbering bits through that pointer. The original value is accessed using car, and the mutation happens opaquely inside the SYSTEM::%RPLACA function. That could be inlined by the compiler, but the model is basically that mutation of objects is done via an API. * The argument evaluation order of standard functions is well-defined, so side effects occurring in argument forms are well sequenced: (let ((x 0)) (list (incf x) (incf x) (incf x))) --> (1 2 3) ;; required result in ANSI Lisp (Scheme bungles this by having less of an opinion; it has C-like unspecified argument eval order.)