"Due to restrictions in the Emacs Lisp language, CLOS cannot be completely supported ... EIEO does not support method dispatch for built-in types and multiple arguments types. In other words, method dispatch only looks at the first argument, and this one must be an EIEIO type."
does not look like it is fully integrated into the core.
> I think there are practical value in keeping that naming scheme
To prohibit reuse of existing code? Where is the practical value? If Emacs Lisp had a namespace mechanism, this would be no topic and nobody would argue keeping a strange naming scheme, where operators are named incompatibly to the language where they were coming from.
Let's define most of Scheme features, but rename all the operators. That's really really strange to argue... I makes the reuse of millions of lines of existing code impossible from day zero.
I've never even imagined copy-pasting straight Common Lisp code into an Emacs Lisp file. And I have to say:
1. The implementations of many functions are subtly different anyway, much like you can't expect Ruby's string join to work the same as Python's string join, down to an identical argument order and everything. That would be crazy to expect, right? You also can't do that kind of thing between Scheme and Common Lisp for what that's worth.
2. Even if you wanted to do this, the name of the function would be the easiest part of the migration: it takes one round of search-and-replace. So the namespacing is not the problem, and it's barely a problem at all.
I'm not really understanding you, maybe. Why would you expect Elisp to be able to run CLisp code verbatim? And why would you ding a language for its inability to fulfil such an uncommon use case?
> I've never even imagined copy-pasting straight Common Lisp code into an Emacs Lisp file.
Just go into a different namespace and load the code. The Lisp Machine I use has several different dialects of Lisp in one image. I can tell what dialect to use and it reads and evals code from that dialect. I can have two REPLs for different Lisps running side by side in one Lisp world, where I can call all operators from all other dialects.
That's basically also what was imagined for a GUILE-based GNU Emacs: it would run all of Emacs Lisp, but would also additionally understand Scheme.
> You also can't do that kind of thing between Scheme and Common Lisp for what that's worth.
Sure I can. Here I have loaded SCHEME into Common Lisp. The namespace is called SCHEME.
Now I switch over to the SCHEME namespace, where I can use the SCHEME operators like DEFINE without prefix:
CL-USER 10 > (in-package "SCHEME")
#<The SCHEME package, 774/1024 internal, 0/16 external>
SCHEME 11 > (foo1 20)
42
SCHEME 12 > (define (foo2 a b) (+ a b 22))
foo2 defined.
SCHEME 13 > (foo2 9 11)
42
> the name of the function would be the easiest part of the migration: it takes one round of search-and-replace. So the namespacing is not the problem, and it's barely a problem at all.
I'm not just talking about migrating code by converting it. I'm also talking about using the same code from one file.
> And why would you ding a language for its inability to fulfil such an uncommon use case?
It's only uncommon because you are not used to it. In earlier times even very complex source code was shareable between similar Lisp dialects.
If one adds to a Lisp lots of operators from a slightly different dialect, then it would be useful to do it in such a way that the dialect is integrated in a way that original source code written in that dialect can be shared with only a minimum of work.
does not look like it is fully integrated into the core.
> I think there are practical value in keeping that naming scheme
To prohibit reuse of existing code? Where is the practical value? If Emacs Lisp had a namespace mechanism, this would be no topic and nobody would argue keeping a strange naming scheme, where operators are named incompatibly to the language where they were coming from.
Let's define most of Scheme features, but rename all the operators. That's really really strange to argue... I makes the reuse of millions of lines of existing code impossible from day zero.