3 ms·

I'm curious what the criteria for this is? And also happy to note elisp is quite effective at extending emacs. Regardless of what it is lacking at large. :)

by taeric 4y ago

lispm 4y ago
Examples: It lacks support for namespaces/modules (where one can control visibilities). Personally I would also think that a standard OOP system would be useful.
- medstrom 4y ago
  But this is odd. When has the lack of namespaces caused a problem to you? When has cl-defstruct or eieio been insufficient to give you what you wanted out of OOP paradigms? I feel like your examples, and multithreading, are just programmers going off surface appearances of modern features and judging before using.
  - lispm 4y ago
    > When has the lack of namespaces caused a problem to you? I can't imagine the maintenance of a Lisp system where several ten thousand names are flat in one namespace. For example: there is no way to browse those just looking at names with prefix parts. Textual name prefixes are a poor substitute for a proper "first class" namespace system. What parts of the symbol name are actually a prefix? "CL-CADDAR" -> that means that I can't load any CL source code into Emacs, because every operator has been renamed. What? There is a subset of Common Lisp in GNU Emacs, but with all operators and variables renamed? 40 years ago Zmacs and the surrounding libraries on a Lisp Machine were already better structured. > cl-defstruct or eieio It's one thing to have features in a language as add-ons and actually having them integrated into the core. The whole optional CL feature & naming debacle shows that there are serious disconnects between developers and the leaders.
    - natrys 4y ago
      > It's one thing to have features in a language as add-ons and actually having them integrated into the core. The whole optional CL feature & naming debacle shows that there are serious disconnects between developers and the leaders. Not really sure what you mean. These are not "add-ons" any more than standard libraries are add-ons to other languages. They are fully integrated into core of Emacs, and has been that way for decades already. The naming situation might imply otherwise, but "cl-" namespace is by no means a second class citizen and I think there are practical value in keeping that naming scheme. In any case they are pervasively used both internally and in the community.
      - lispm 4y ago
        "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.
        medstrom 4y ago
        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?
- taeric 4y ago
  Namespaces is an odd one. In general, I've seen more woes from junior programmers over optimizing for "private visibility" than I have noticed the benefits. I can't claim there have been no benefits, so I cede it could be confirmation bias on my part. Still, I don't want to just turn to nitpicking the examples. I asked, you gave. I'll think on those some. I stand by my assertion that the abstractions are good for what emacs needs. As evidenced by how well it does keep up, all told. Does it do as well as a staffed resource to build some resources? Probably not. More, it is unlikely to ever be able to make a feature that nothing else can do. By virtue of it being open. If something is amazing from it, others can emulate it. But, the amount of synergy between modules speaks volumes. Tramp alone is quite amazing at how many modes "just work" with it. With no prior planning on having to expose internals or special methods. I also confess I expected threading to be mentioned. Another thing which I have seen cause as many errors as it typically helps. Effectively the "goto" of application development. Often best avoided, but also often required.
  - lispm 4y ago
    I'm not up to date what GNU Emacs does with by default concurrent threads of Lisp code on multiple cores. What is the story there? I would think that each Zmacs instance from 40 years ago already ran in its own thread.
    - taeric 4y ago
      My impression has been that emacs itself does fine with multiple processes. As seen by the compilation buffer being fine. So, if you setup a sentinel and do the process buffer technique, things can be done. Most people lament the lack of threads, though. More, I think most people do not want to build the necessary stuff for a process buffer to help. Happy to know where I'm mistaken there. And I've certainly seen places where a blocking call can be annoying. Usually creeps up into a place that was fine at first. Org mode source execution is a good one. For the vast majority of stuff I do in those, I'm fine that it blocks while it gives me the results. Then I'll kick off one block that I should have added the async flag to, but just didn't.

I'm curious what the criteria for this is? And also happy to note elisp is quite effective at extending emacs. Regardless of what it is lacking at large. :)

by taeric 4y ago

I'm curious what the criteria for this is? And also happy to note elisp is quite effective at extending emacs. Regardless of what it is lacking at large. :)

lispm 4y ago

Examples: It lacks support for namespaces/modules (where one can control visibilities). Personally I would also think that a standard OOP system would be useful.

medstrom 4y ago
But this is odd. When has the lack of namespaces caused a problem to you? When has cl-defstruct or eieio been insufficient to give you what you wanted out of OOP paradigms? I feel like your examples, and multithreading, are just programmers going off surface appearances of modern features and judging before using.
- lispm 4y ago
  > When has the lack of namespaces caused a problem to you? I can't imagine the maintenance of a Lisp system where several ten thousand names are flat in one namespace. For example: there is no way to browse those just looking at names with prefix parts. Textual name prefixes are a poor substitute for a proper "first class" namespace system. What parts of the symbol name are actually a prefix? "CL-CADDAR" -> that means that I can't load any CL source code into Emacs, because every operator has been renamed. What? There is a subset of Common Lisp in GNU Emacs, but with all operators and variables renamed? 40 years ago Zmacs and the surrounding libraries on a Lisp Machine were already better structured. > cl-defstruct or eieio It's one thing to have features in a language as add-ons and actually having them integrated into the core. The whole optional CL feature & naming debacle shows that there are serious disconnects between developers and the leaders.
  - natrys 4y ago
    > It's one thing to have features in a language as add-ons and actually having them integrated into the core. The whole optional CL feature & naming debacle shows that there are serious disconnects between developers and the leaders. Not really sure what you mean. These are not "add-ons" any more than standard libraries are add-ons to other languages. They are fully integrated into core of Emacs, and has been that way for decades already. The naming situation might imply otherwise, but "cl-" namespace is by no means a second class citizen and I think there are practical value in keeping that naming scheme. In any case they are pervasively used both internally and in the community.
    - lispm 4y ago
      "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.
      - medstrom 4y ago
        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?
taeric 4y ago
Namespaces is an odd one. In general, I've seen more woes from junior programmers over optimizing for "private visibility" than I have noticed the benefits. I can't claim there have been no benefits, so I cede it could be confirmation bias on my part. Still, I don't want to just turn to nitpicking the examples. I asked, you gave. I'll think on those some. I stand by my assertion that the abstractions are good for what emacs needs. As evidenced by how well it does keep up, all told. Does it do as well as a staffed resource to build some resources? Probably not. More, it is unlikely to ever be able to make a feature that nothing else can do. By virtue of it being open. If something is amazing from it, others can emulate it. But, the amount of synergy between modules speaks volumes. Tramp alone is quite amazing at how many modes "just work" with it. With no prior planning on having to expose internals or special methods. I also confess I expected threading to be mentioned. Another thing which I have seen cause as many errors as it typically helps. Effectively the "goto" of application development. Often best avoided, but also often required.
- lispm 4y ago
  I'm not up to date what GNU Emacs does with by default concurrent threads of Lisp code on multiple cores. What is the story there? I would think that each Zmacs instance from 40 years ago already ran in its own thread.
  - taeric 4y ago
    My impression has been that emacs itself does fine with multiple processes. As seen by the compilation buffer being fine. So, if you setup a sentinel and do the process buffer technique, things can be done. Most people lament the lack of threads, though. More, I think most people do not want to build the necessary stuff for a process buffer to help. Happy to know where I'm mistaken there. And I've certainly seen places where a blocking call can be annoying. Usually creeps up into a place that was fine at first. Org mode source execution is a good one. For the vast majority of stuff I do in those, I'm fine that it blocks while it gives me the results. Then I'll kick off one block that I should have added the async flag to, but just didn't.