7 ms·

> Pretty sensible in a dynamic language. For a dynamic language I would expect to be able to change objects, in many ways. Otherwise it would not be 'dynamic',

by lispm 10y ago

> Pretty sensible in a dynamic language. For a dynamic language I would expect to be able to change objects, in many ways. Otherwise it would not be 'dynamic', but 'static'. > (2) Common Lisp: Only primitives are values, and mutating anything else is permitted. But not necessarily possible. In this Common Lisp example there is no way to change the closure bindings. CL-USER 107 > (let ((f (let ((a 10) (b 10)) (lambda (x) (+ x a b))))) (* (funcall f 1) (funcall f 2))) 462

catnaroek 10y ago
> For a dynamic language I would expect to be able to change objects, in many ways. That objects must support mutation was never in question. All general-purpose languages have mutable objects. The point is whether you also want to have compound values. I think the answer should be “yes”. > In this Common Lisp example there is no way to change the closure bindings. Point taken. But I hope you aren't suggesting me to Church-encode compound values. Even ignoring the usability issues of Church encoding, there's still the problem that Common Lisp will treat two otherwise extensionally equal functions as different objects. :-p
- qwertyuiop924 10y ago
  ...but, the functions are side-effectless, and guaranteed not to change, so you can just equal? the results. Basically, you can use function as const.
  - deleted 10y ago
    [deleted]
  - catnaroek 10y ago
    > ...but, the functions are side-effectless, and guaranteed not to change, so you can just equal? the results. Just because (f 1) and (g 1) are equal, it doesn't automatically follow that f and g are equal. Functions shouldn't be comparable for equality at runtime, because extensional equality of functions is undecidable.
    - qwertyuiop924 10y ago
      sigh not what I meant. I MEANT that you can model immutable variables using functions.
      - catnaroek 10y ago
        Will `equal` work correctly on immutable values modeled as functions? No? I guessed just as much.
        qwertyuiop924 10y ago
        well, you'd have to unwrap the values first. The call would be: (equal variable (constant)) whether you think that's acceptable or not is up to you.
        catnaroek 10y ago
        The encoding of compound values as functions is actually more complicated than that: ;; pair constructor (defun make-pair (x y) (lambda (f) (funcall f x y))) ;; projection from pairs (defun former (x y) x) (defun latter (x y) y) ;; test pairs (defvar foo (make-pair 1 2)) (defvar bar (make-pair 1 2)) ;; equality test (defun equal-pairs (x y) (and (equal (funcall x #'former) (funcall y #'former)) (equal (funcall x #'latter) (funcall y #'latter)))) ;; try it (equal-pairs foo bar) And this was just for pairs of primitive values. You don't even want to imagine how painful it is to represent arbitrarily complex compound values this way.
tome 10y ago
> For a dynamic language I would expect to be able to change objects, in many ways. Otherwise it would not be 'dynamic', but 'static'. That's not what "dynamic" vs "static" means. Are you suggesting that "static" languages don't allow you to change objects?!

by lispm 10y ago

catnaroek 10y ago

> For a dynamic language I would expect to be able to change objects, in many ways. That objects must support mutation was never in question. All general-purpose languages have mutable objects. The point is whether you also want to have compound values. I think the answer should be “yes”. > In this Common Lisp example there is no way to change the closure bindings. Point taken. But I hope you aren't suggesting me to Church-encode compound values. Even ignoring the usability issues of Church encoding, there's still the problem that Common Lisp will treat two otherwise extensionally equal functions as different objects. :-p

qwertyuiop924 10y ago
...but, the functions are side-effectless, and guaranteed not to change, so you can just equal? the results. Basically, you can use function as const.
- deleted 10y ago
  [deleted]
- catnaroek 10y ago
  > ...but, the functions are side-effectless, and guaranteed not to change, so you can just equal? the results. Just because (f 1) and (g 1) are equal, it doesn't automatically follow that f and g are equal. Functions shouldn't be comparable for equality at runtime, because extensional equality of functions is undecidable.
  - qwertyuiop924 10y ago
    sigh not what I meant. I MEANT that you can model immutable variables using functions.
    - catnaroek 10y ago
      Will `equal` work correctly on immutable values modeled as functions? No? I guessed just as much.
      - qwertyuiop924 10y ago
        well, you'd have to unwrap the values first. The call would be: (equal variable (constant)) whether you think that's acceptable or not is up to you.
        catnaroek 10y ago
        The encoding of compound values as functions is actually more complicated than that: ;; pair constructor (defun make-pair (x y) (lambda (f) (funcall f x y))) ;; projection from pairs (defun former (x y) x) (defun latter (x y) y) ;; test pairs (defvar foo (make-pair 1 2)) (defvar bar (make-pair 1 2)) ;; equality test (defun equal-pairs (x y) (and (equal (funcall x #'former) (funcall y #'former)) (equal (funcall x #'latter) (funcall y #'latter)))) ;; try it (equal-pairs foo bar) And this was just for pairs of primitive values. You don't even want to imagine how painful it is to represent arbitrarily complex compound values this way.

tome 10y ago

> For a dynamic language I would expect to be able to change objects, in many ways. Otherwise it would not be 'dynamic', but 'static'. That's not what "dynamic" vs "static" means. Are you suggesting that "static" languages don't allow you to change objects?!