Brian Marick
What commonly-used programming languages have a single global namespace, such that you can redefine core functions? The only one I can think of is Emacs Lisp.
(Whereas you can redefine `+` in Ruby, that doesn't override the `+` the actual Ruby runtime uses. That's what I'm getting at with "global namespace".)
Alfred M. Szmidt
@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.
Brian Marick
@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.
luciano
@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/
Alfred M. Szmidt
@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.
Brian Marick
That's different from how, in Ruby, you can change `Integer::+` and have it not affect all the additions the interpreter does (because, in this case – I believe – all the additions have been compiled to machine code).
In early Lisps, there was one namespace, so people could easily stomp on functions used by the interpreter. Same effect as compiling to machine code. (2/2)
Brian Marick
@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)
Alfred M. Szmidt
@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).
Alfred M. Szmidt
@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.
Alfred M. Szmidt
@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”
Brian Marick
@amszmidt It's been more than 40 years since I spent my time disassembling Lucid Common Lisp's compiler output (to find out the clever efficiency hacks they used, in service of Gould Common Lisp), so I can't be sure, but I'm sure that it compiled a large set of primitives into inline machine code, with no level of indirection through a lookup table.
So you couldn't affect the interpreter by redefining `car`.
That's what I was (clumsily) alluding to.
Alfred M. Szmidt
@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…..
Brian Marick
@amszmidt It may have been a higher optimization setting (I seem to remember you could, for example, turn off detecting overflow and converting a fixnum into a bignum).
But I really do think the Maclisp/Common Lisp folk were pragmatic about the realities of efficiency: function calls were *expensive* back then, and tolerated differences in behavior between compiled and interpreted code in a way that seems very foreign today.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.