3 ms·
Yeah... C is not Lisp, okay. :-) But that only strengthens the point: language features are just abstractions we use to reason about data. One can always strip
by vkazanov 8y ago
Yeah... C is not Lisp, okay. :-)
But that only strengthens the point: language features are just abstractions we use to reason about data. One can always strip all the abstractions and end up working with raw bits.
If there's a useful way to think about certain kinds of data - it might be useful to codify that way as a language feature. Such as specialised error handling.
- kazinator 8y agoIn Lisps, a function is also just a reference, and not the object itself. You can't take its size or copy it. (You could copy it if your dialect provided a copy-function function, of course. I don't think I've ever seen one. Such a thing could be useful if it provided a frozen copy of a closure's lexical environment, that would be unaffected by mutations when the original copy of the function is invoked.)
- kazinator 8y agoOkay, I will try to explain it to the downvoter. Suppose we have a lambda like this: (let ((counter 0)) (lambda () (incf counter)) When we evaluate this we get a function. It contains the captured lexical environment. If we call that function, the captured counter variable mutates. Now suppose we had a copy-function library function. I would expect it that if we apply it to this function, we get an object which carries a duplicate of the lexical environment. This means it has its own instance of counter. If we call the original function, the copied function's counter stays the same and vice versa. I don't remember seeing such a copy-function in any Lisp dialect; there isn't one in ANSI CL. It seems it might be useful, same as the ability to copy a structure or OOP object.
- deleted 8y ago[deleted]