Back

@marick saw someone mention smalltalk... does method swizzling in Objective C count?
https://developer.apple.com/documentation/objectivec/1418769-method_exchangeimplementations
https://nshipster.com/method-swizzling/

@luciano I think so. You can redefine `+` in Ruby and not blow everything up because you don't have access to the "real" definition (compiled in). Method swizzling sounds like what you can easily do in Emacs Lisp: which is stomp on a defined function.

But I think a core distinction I ignored is the difference between definitions that are compiled into machine language (`+`) and those that are not. The question was not a good one.

@marick Scheme? Plenty of languages let you redefine existing functions...

Though it has little to do with compiled or not compiled. Emacs Lisp can be compiled to machine code, or byte code. In Common Lisp the same .. and even there you can re-define existing functions in a different "package".

What matters is how function look up is done, and I suspect that you can redefine + in Ruby as well. Not so much namespaces.

@luciano

@amszmidt @luciano You're right. But: I was looking for trivia to highlight that human language has no mechanism for protecting old definitions from new changes. Specifically, consider how "literally", "awesome", and "sublime" mean different things than they used to. Suppose a dictionary changes its definition of "awesome." That will change, subtly probably, the meaning of every definition that uses that word. (1/2)

@marick I'm not sure I follow, in Common Lisp you have separate name spaces.

CL being one specific package that contains the definition of +. (defun CL:+ (a b) (cl:* a b)) is possible, and will cause all kind of weird behavior.

Redefining integer::+ in Ruby would (I presume) have the exact same cause.

It has nothing to do with the functions being compiled to machine code or not, in the CL example this can be compiled to machine code and often is in e.g., SBCL.

@marick In Lisp the way it works is that when you do a function call, you look up the _symbol_ you don't jump to the symbol value to execute it at some hard coded address. When you redefine a function all you do is modify that symbols value.

If that is machine code, text, interpreted, is not very important. You can still stomp any function in essentially any Lisp just as easily as "early" Lisp (not sure what that means).

@marick And after thinking, I think I understand what you mean with natural languages.

They are like Lisp, Scheme, Forth, ... in how redefining a function can cause change to any definition that is already used due to how the calls work.

@amszmidt Yes. I have this analogy to how, from the time of Pythagorus (coping with Zeno's paradoxes) through Newton and Leibniz, math people shoved analogous paradoxes down into what were variously called "indivisibles" and "infinitesimals"¹ so they didn't have to deal with them. (They had better things to do, and the unsoundness only got cleaned up in the later 1800s.) (1/2)

I'm trying to explain Jacques Derrida to techies, and I'm going with "general ideas about how language works is you can shove the weirdities down into something like indivisibles, but Derrida says, nah, that doesn't work. [which is sort of an empirical question]

¹ https://en.wikipedia.org/wiki/Cavalieri%27s_principle (2/2)

@marick might have been an implementation glitch, all CL implementation i know of you can redefine CAR even if it is implemented “not via DEfUN”

@marick I know that Maclisp did a lot of optimization on FP (cause Macsyma); and that compiler and interpreter a behaved entierly differently (still does on LispM ).
But that funcalls where specially managed I’ve not seen much of, you could always redefine a function in Maclisp even if it was compiled. The semantics of the whole language would become quite wonky…..