Not sure exactly about ordering: most other HOPL papers follow a mostly chronological organization, so I guess we could do the same?
However, HOPL 2 / Lisp has:
https://www.cs.umbc.edu/courses/331/resources/papers/Evolution-of-Lisp.pdf
- History in terms of projects and people: XEmacs was going strong when Emacs wasn’t
- Evolution of the language in technical terms
How ‘bout: 1- prehistory (Mocklisp and Maclisp) 2- early history (Emacs until the big schism) 3- XEmacs 4- Emacs Given that XEmacs’s development was most active when Emacs’s was most dormant and vice-versa, this ends up being almost chronological.
https://www.emacswiki.org/emacs/EmacsHistory https://www.jwz.org/doc/emacs-timeline.html https://www.jwz.org/doc/lemacs.html https://www.xemacs.org/Documentation/21.5/html/internals_3.html http://www.multicians.org/mepap.html https://en.wikipedia.org/wiki/Mocklisp https://www.gnu.org/gnu/rms-lisp.en.html http://www.softwarepreservation.org/projects/LISP/embedded/#Emacs_Lisp_ https://www.math.utah.edu/docs/info/elisp_toc.html ftp://ftp.gnu.org/old-gnu/Manuals/
https://news.ycombinator.com/item?id=8727085 http://bitsavers.informatik.uni-stuttgart.de/pdf/cmu/Gosling_Unix_EMACS_Dec81.pdf
- type opacity - keymaps, events?
Edwin, there’s also a paper on this: https://archive.org/stream/bitsavers_mitaiaimAI_794650/AITR-1451_djvu.txt In “down with emacs lisp” you also mention JEmacs.
Mention Neubauer/Sperber ICFP 2011 paper
I’m thinking here of how when/unless/dolist/push/setf slowly migrated from CL to subr.el in Emacs.
indent, debug, doc-string, advertized-calling-convention, …
> We trace the overall evolution of Elisp in the software projects that > implemented it. Its predecessors EINE (1976) and Multics Emacs (1978) > were themselves written in Lisp.
Was Eine Initially), buffer-modifying primitives took arguments to specify what text to operate on. I found that clumsy, so in Emacs Lisp I made them operate at point.ISTR that in Multics Emacs, NO buffer primitives let the user specify positions. It was always and only operating at point. I found that too clumsy. So Emacs Lisp has some primitives that operate where an arg says, and some that operate at point.
The original Emacs was dsveloped in 1976, by me with some help from Guy Steele.
I started GNU Emacs around Sep 1984.
> its development slowed down and was overtaken by Lucid Emacs, later > renamed XEmacs,This is because Lucid hired the Emacs developer away from the FSF.
NOTE: I don’t see supporting documentation for this - when Lucid Emacs overtook Emacs, Joe Arceneaux was no longer working on the project.
> influences for Elisp were Gosling Emacs’s Mock Lisp and MacLisp.Nocklisp (that’s how it was written)
NOTE (Mike): Gosling’s manual for Unix Emacs says “Mock Lisp”
had very little influence, since I decided very early to replace it with real Lisp. In Mocklisp, primitives all operated at point. I made the corresponding features of Emacs Lisp less clunky.
> the ideals of Free Software. For example, not only is it legal to get > and modify the source code, but every effort is made to encourage the > end-user to do so.Indeed, there is no law saying that the user can’t do this (because it is free software, released under a free software license). But is that what you mean? Is “legal” the right word to use here?
> among them the `do` loop construct, and the accompanying `return` and > `go` forms for non-local control transfer.The reason I left them out was to make Emacs work on Unix systems which had just 1 meg of memory and no virtual memory.
> self-documentation through docstrings, described in > Section [4.4](#sec:docstrings){reference-type=”ref” > reference=”sec:docstrings”}.These came from the original TECO-based Emacs.
> Elisp language until around 1991 when it was added as a macro, early > during the development of Emacs-19.That is not correct. Functions were lists starting with `lambda’ since the very beginning of GNU Emacs.
However, those lists did not self-evaluate until `lambda’ was made a macro.
> because Richard Stallman considered it a misfeature, which could make it > difficult to debug the code. Yet this very feature was finally added to > Elisp in 2018 in the form of variable watchers, though they are > ironically mostly meant to be used as debugging aides.This is not ironic. We avoid using them as an extension mechanism because that makes the code hard to debug. Using them as a debugging method does not have such a problem.
> in MacLisp and Lisp Machines, that allowed attaching code to functions > even if they do not run hooks.It is bad practice to make a Lisp program put advice on another Lisp program’s function, because that is confusing. When you see that the program calls `mumble’, it might take you hours before you think of checking whether it has advice.
typo,
> of Emacs 19, the required cooperation between Lucid and the Free > Software Foundation soon broke down.The reason for this is that the Lucid Emacs team never discussed it with me. The head of Lucid wanted them to cooperate with me and the GNU Project, but they did not even tell me that they were developing on changes in Emacs until their version was finished. My first discussion with them about the design of their new features was after that – and their attitude was, “The code is free, use it if you want it, but we don’t care.”
I liked some of their features enough to merge them into Emacs, for instance the display features. I did not like the extents, so I used instead the text properties that Joe Arceneaux had been working on (but he had left the code unfinished when he went to Lucid on short notice).
NOTE (Mike): Dick Gabriel’s account of that period in https://www.jwz.org/doc/lemacs.html differs from this, so I think it’s likely best to elaborate on why that cooperation broke down at this point.
symbols with the same abbreviated name inevitably work badly. That was my experience with Common Lisp in the Lisp Machine.Scheme’s module system can work reasonably because it operates when determining the binding of a symbol, not when reading the symbol.
NOTE (Mike): No historical note here.
> the kind of scoping used in the sense that either dynamic or lexical > scoping gives the same result in almost all circumstances.As written, this is not true. Lots of Emacs Lisp programs bind global variables that serve as parameters to certain operations. They depend on these bindings to be dynamic.
===========================================================================
Overall merit
- Weak accept
Reviewer expertise
- Some familiarity
Paper summary
The paper describes the development of Emacs Lisp and related systems such as XEmacs Lisp. It is organised into “epochs”
- Prehistory
- Early history
- Base language design
- Base language implementation
- XEmacs period
- Emacs/XEmacs co-evolution
- Post XEmacs
- Alternative implementations
The paper often seems light on citations, often describing a whole development with no citations, not even to its documentation. The exposition often assumed knowledge I did not have, such as familiarity with CLOS.
will hold for the general community. There certainly are points of interest. The conclusion refers to “willingness to break backward compatibility in specific cases” and “unbridgeable personal differences, heated debates, and forks along the way”. I think a paper of greater value and greater general interest could be derived by structuring it around these issues, omitting much of the other detail.Comments for author
are we to assume there is no documentation and it is down to personal knowledge of the authors? Please add citations wherever possible. years, and relating release numbers for Emacs to those for XEmacs. Could you give a table with a chronology of releases? the introduction a little about your involvement with Emacs and to what extent (if any) you consulted with the community in writing this paper. you should say something regarding Stallman’s biography. He is mentioned with regard to specific details, but you should also say something about his overall role in the history. I recommend you use third person throughout. “Following Greenberg’s Multics Emacs” Citation please! know it. This section says nothing about lexical vs dynamic scope. As dynamic scope seems a pretty backward design choice for 1985, it would be helpful to say something about why it was chosen. (This is finally discussed in 8.1. Moving some of that discussion ahead, or at least giving a forward pointer, would help.) A word on why lambda was omitted would be helpful. Can you interview Stallman? It’s a little weird that you show in detail the syntax for the Emacs-18 workaround, but you don’t describe the Emacs-19 macro. “With buffer-local variables” –> “Along with buffer-local variables” “It could either denote …” Please rephrase. I guess one of these means (` a) and one means (`a), in the old-style notation, but I can’t tell which is which. “has to do with region selection” This is mysterious—how does the region affect this function? “run a hook” Please explain what this means. I’m guessing it means to execute each function in the list. Are the functions required to take no arguments, or, if they have arguments, which are passed? attach a single function to another function? Or a list of functions, as in a hook? Does the attached function run before the other function, or at some other time?
- CLOSING NOTE [2019-05-22 mer 19:26]
I added two examples of the simplification
give a citation.
best to reorder them, with the ones directly related to Emacs first (e.g., 4.2, 4.5, 4.7, 4.9), then ones tied to Emacs goals (e.g., 4.4, 4.8), and the ones that are only incidental later (e.g., 4.1, 4.3, 4.6).4.1 Lambda 4.2 Strings 4.3 Backquote 4.4 Docstrings 4.5 Interactive functions 4.6 Non-local exits 4.7 Buffer-local variables 4.8 Hooks 4.9 I/O
Suggestions:
4.2 Strings 4.5 Interactive functions 4.7 Buffer-local variables 4.9 I/O
4.4 Docstrings 4.8 Hooks
4.1 Lambda 4.3 Backquote 4.6 Non-local exits
Note from Mike: I ordered it a bit differently, with core language features being first - connecting to the MacLisp section immediately prior.
- CLOSING NOTE [2019-08-19 lun 18:22]
Clarified that the byte-compiler was there from the very beginning
Who developed the byte-code compiler? Citations, please.
“FSF-owned” I guess this is the Free Software Foundation? But you haven’t mentioned it by name at this point. “where amply sufficient” –> “were amply sufficient”- CLOSING NOTE [2019-05-22 mer 19:27]
It was explained in the following sentence, so I reworded to clarify
purpose, how were objects marked?
worthwhile to list them all? this phrase refers to, please rewrite. “ephemerons” Are these so uninteresting that they deserve no description in the paper? “no matter which tagging scheme we used” Change from first to third person. even fixnum tags mentioned earlier. by Common Lisp, but you ought to be clear about this. “the more standard forms of weak references” I don’t know what this means. function bodies was brittle and inconvenient and only worked for functions defined in Elisp.” Delete the similar phrase from the next paragraph. “but did get” –> “But it did get” does not mean the feature was released, since it is still an attempt.) it would be best to move the information in the first three paragraphs of Section 6 to before Section 4. Lucid Emacs? Section 6.1. I gather the purpose of a keymap is to map a sequence of keystrokes to a function to invoke. Please say this explicitly. Please also explain nesting of keymaps. keymap. into existence? “While no significant changes were made to the byte-code format in XEmacs, the two instruction sets eventually drifted and became incompatible.” Surely the first incompatible change was significant, just because it was incompatible? Make clear whether the drift was a deliberate choice or an accident.- CLOSING NOTE [2019-05-22 mer 19:28]
I gave an example of a lack of unification
“it was not unified with other charsets” I don’t know what this means.
“This issue is still being discussed with Emacs.” –> “This issue is still being discussed in the Emacs community.” more detailed than other discussion, and it seems more detail than necessary. “during that time” Unclear. Replace by “post-2010” or whatever is correct.“”hidden” configuration options” I’m not sure what “hidden” adds
- CLOSING NOTE [2019-05-22 mer 19:30]
I added an example to clarify
“except in the presence of higher-order functions, like reduce” I don’t understand why higher-order function would lead to name conflicts under the described convention.
- CLOSING NOTE [2019-05-22 mer 22:47]
It was explained, but I guess it was not clear that Miles Bader’s approach is the one we use, so I reworked the wording to make it more clear. I also added a paragraph discussing how the new feature was accepted.
I take it that in the current version lexical scope is the default, but that dynamic scope is still possible. You should say something about how this is achieved. You should also say how backward compatibility was maintained. Was this done by static analysis or two languages, both described previously, or by some other means? How smoothly did the introduction of lexical scope go?
Has lexical scoping made its way into XEmacs?
- CLOSING NOTE [2019-05-22 mer 22:51]
I just removed it
“often using the new low-level pattern app”. I have no idea what this means. Explain or omit.
“we” Perhaps change to third person?- CLOSING NOTE [2019-05-25 sam 23:38]
Clarified the relationship between the two and added a sentence about future plans and maintenance cost
I take it that both cl.el and cl-lib.el are currently in use. Does this introduce any performance or maintenance issues? Are there plans to deprecate cl.el?
but now it uses “generalised variable”. Perhaps change the earlier occurrences of “generalised reference” to “generalised variable”. as an …”- CLOSING NOTE [2019-05-26 dim 00:04]
I added a paragraph which explains what each part of the tuple does
explanation. How does STORE-VAR relate to VARS? The expansion of (push EXP PLACE) helps little unless the reader knows how push is defined. This paragraph should be rewritten with more explanation.
- CLOSING NOTE [2019-05-26 dim 00:06]
In my experience the two are closely linked, but I rewrote it to clarify
code was hard to follow”!
- CLOSING NOTE [2019-05-26 dim 00:13]
Indeed the “DO” was confusing. I eliminated it and clarified the role of gv-get-place-function along the way
gv-get-place-function in the following example? Please rewrite to clarify.
- CLOSING NOTE [2019-05-26 dim 00:15]
OK, done
Nothing is gained by giving two forms of the push example. Just give one or the other.
- CLOSING NOTE [2019-05-26 dim 00:17]
You don’t directly get access to STORE-FUNCTION and ACCESS-FORM (it’s only provided to a callback which may be called any number of times and has to return code which will be inserted within other code under the control of the place), so yes, technically you can hack something up that will often work, but it’s definitely not “easy” nor robust.
“the reverse is not true” Why can’t you set (VARS VALS STORE-VAR STORE-FORM ACCESS-FORM) to (nil nil x (STORE-FUNCTION x) ACCESS-FORM) ?
Emacs-18.51 in 1988)” Doesn’t belong here. Add the last phrase to the earlier mention of cl.el on p26. Common Lisp Object System. mention of CEDET in the previous paragraph.- CLOSING NOTE [2019-05-26 dim 01:04]
I added a paragraph briefly explaining CLOS
“supported specializers” I’m not familiar with CLOS, and I don’t know what a specializer is. Please explain. Indeed, please rewrite the whole section assuming your reader is not familiar with CLOS.
- CLOSING NOTE [2019-05-26 dim 01:11]
I added a sentence explaining what this means
- CLOSING NOTE [2019-05-26 dim 01:26]
Added a paragraph explaining the relationship between the various parts and their deprecation status
use? Does this introduce any performance or maintenance issues? Are there plans to deprecate EIEIO?
“the generator.el” –> “generator.el” continuation-passing style” I don’t see why this should be the case, please explain. “async.el” Cite its documentation.- CLOSING NOTE [2019-08-19 lun 19:10]
Explained the current state of use
Have the uses led to concurrency bugs? If there aren’t many uses of the package yet that would also be valuable information.
optimizations, for example” problem? How? How widely used is define-inline? How does it co-exist with the older systems for inlining?“¡pkg¿” font issue?
“Emacs-Ejit” I presume this is the compiler from Emacs to Javascript? Please make this explicit.
“willingness to break backward compatibility in specific cases” It would be good to make this a theme of the paper, stressing where it happened, how the evolution was handled, and how successful it was.
the way” These are all great topics for a history! But the paper largely ignores or downplays these.
that you list are already covered in Section 4! Were there later ones?Mike: want to cover customize
about the composability of packages, not of the community.===========================================================================
Overall merit
- Weak reject
Reviewer expertise
- Knowledgeable
Paper summary
This paper describes the design and implementation of the Elisp language as part of the Emacs text editor over the course of thirty years.
Comments for author
ASSESSMENT
Overall, this paper is not yet ready for HOPL in its current state. Perhaps with shepherding it could be made acceptable, however, it will take a lot of work.
The biggest problem with this paper is that it does not tell a compelling story. It is a historical account, but much of its telling lacks any discussion of context. It covers a lot more ground describing what happened, but does not explain why it happened or what the result was. I think the issue is that the authors have favored breadth over depth–a lot of changes have been made to Elisp since 1985! But it is the job of the authors to identify the most important changes and events, so that they can make their points.
The best part of the story is when the paper talks about the interactions between the designs of the language and the constraints of being the scripting language for an editor, and of the constraints that come from being part of the free software movement. I wish this part of the story were told more consistently and more prominently.
analysis. I can only assume that the there were other reasons for these changes, besides the two listed above, but I would rather not have to guess. sections, I found myself wondering, what should I take away from this section? What can I learn from it? How does it fit into the overall story? In particular, although it is notable that some features that require primitive support in other languages can be implemented via macros in Elisp (e.g. lambdas, objects, pattern matching, generators, modules) this is also true for other LISP variants. What is unique here? Perhaps it would be better to focus on the ones that have more close connection to Elisp----for example, the ones that are difficult to implement in the presence of dynamic binding. I wish the paper described this feature & the introduction of static binding in a more self-contained way, rather than scattering it throughout the text. I also wish that it were more complete. What were the initial advantages of dynamic binding? What made static binding ultimately possible? How has the change affected the community? casual Emacs user for over twenty years (I am using it now to type this review), I have encountered some of Elisp, and as a programming language researcher, I am curious about its history. However, some parts of this paper assume the knowledge of an Emacs developer! Why not broaden the audience and make the paper more accessible?SPECIFIC COMMENTS and ADVICE
scientist should be a independent observer. But that isn’t the case for history. Please introduce yourselves at the beginning of the paper and lay out your connection to the material. This lets the reader better put this material in context—are you telling us material that you have first hand knowledge of because you were there, or is this something that you heard from someone else? description of Emacs the software artifact. I believe this is a deliberate choice by the authors to blend these descriptions, and is probably justified, but at the same time it left me off kilter. outlines the major milestones in the development of Emacs. In particular, the discussion lists various version releases (e.g. Emacs-24.3) without providing dates for these releases. Also, sometimes the discussion includes a minor number with the release (e.g. Emacs-19.29) and sometimes it doesn’t (e.g. Emacs-19). Is there a semantics to the major/minor numbers of the release?This timeline, and a capsule summary of the major software artifacts discussed in the paper, will help later discussion immensely.
free software movement is, and what the GPL requires. Although many readers may already know this story, establishing the details that are important to later design decisions is a good introduction. Instead, the first time Stallman is introduced is the sentence “Richard Stallman decided to reimplement the basis for the new Emacs in C…” which I found really confusing. What was his first implementation? short and jumps around too much. The introductory sentence “While Emacs’s original inception was a set of macros for the TECO editor” puts me off right from the start. Should I know what the TECO editor is? Was this the first thing ever called Emacs? Who created the name Emacs and where did it come from? (Or is it lost to history?) The two sub-sections in section 2 also do not add much beyond what has already been said. What is the relationship between EINE and MacLisp? (And MacLisp is a programming language, not an editor, right? Is the editor that was written in MacLisp the one later called “Greenberg’s Multics Emacs”?) How did MacLisp influence Elisp?In 2.2, what do you mean when you way “Unix Emacs … was one of the immediate predecessors of Emacs”? What is the specific software package that you are referring to with the name “Emacs” at this point. Who wrote it? When?
rule” and “Eight Megs And Constantly Swapping”. These are both presented as if the reader is already familiar with them, which is a way to turn off readers. Mentioning them without explanation gives the impression that you only expect people already familiar with them to read this article. How limiting! 4.1, to be boring, repetitive and unhelpful. I never read them. consequences of lambda being a macro. Why wasn’t the original Elisp code ever updated to use this new lambda form over 30 years? What is the #’ … reader shorthand referred to at the end of page 6? to be split between it and 4.7. What are buffer local variables? How does that make strings a fancier datatype than in most other languages? What is the impact of storing strings with variable numbers of bytes? Why is moving the string’s bytes elsewhere on update an issue? Why is XEmacs “modified-tick” feature worth mentioning when it has apparently never been used?backwards-incompatible changes, which is both tedious in detail but leaves me wanting to know more. What is the context of the design changes discussed in this section (i.e. introducing explicit warnings in Emacs-22.2)? How did users react to them? What changed so that the old-style syntax could be removed in 2018? Why could it not be changed earlier?
by language designers? Are there trade-offs in including this feature in Elisp? What percentage of Elisp code uses docstrings? How searchable is it? What other languages, besides Common Lisp, have adopted it?- CLOSING NOTE [2019-08-19 lun 19:26]
Removed this irrelevant detail
- CLOSING NOTE [2019-08-19 lun 19:55]
Mentioned its popularity with example uses; gave more details about nadvice
different? What sort of advance was it?
I wonder if focusing on the dynamic to lexical scoping evolution would make for a tighter, more compelling read. implementation of Elisp, underwhelming. Partly it is my biases — most of these changes are invisible to users, except when they remove limitations on heap size and file size. However, partly this is because this section does not discuss the context of these changes. What pressures were in play? How did changes, to say, data representation, affect users? libraries? runtime? FFI? indicated when GC was in progress.” This sentence, presented with minimal discussion, makes me sad. Sure, user complaints about GC decreased as a result, but is that because users were deceived? Or were the messages incorrect? Or were the user perceptions wrong to begin with? Was this the right thing to do? example? What is important about the current representation? Overall, the discussion in this section is one of software engineering experience: should a particular data structure in the implementation of Emacs be represented concretely or abstractly. How does this relate to the design of Elisp? characters, as the development team grows. However, there is no high-level discussion about how the development teams for Emacs and XEmacs were composed, lead and organized. Were they both open-source projects? How big were the teams? Did Stallman always control everything to do with GNU Emacs? How did the teams communicate with each other (if they did so)?- CLOSING NOTE [2019-08-19 lun 20:37]
I added a paragraph explaining the relevance
uninteresting and really reads like a changelog. I have no idea what these functions are or why their integration is important.
developers don’t want to rely on an IDE makes me despair as a language researcher. If any language can make assumptions about its development environment… offend anyone by leaving them out”. As a reader, I didn’t get much out of it. see where “a maintainership which was more interested in improving the text editor than the language” was discussed earlier in the paper. What actions is this comment in reference to? The paper also is rather oblique about discussing the “unbridgeable personal differences, heated debates, and forks along the way”. This is the place to record the controversies, right or wrong, as they are part of the history.===========================================================================
Overall merit
- Strong accept
Reviewer expertise
- Some familiarity
Paper summary
The paper traces the evolution of ELISP as the Lisp based macro facility of Emacs. It discusses the language evolution, but more than that how the system that it was a part of evolved over time…and how the system often changed the language more than the language designers did.
Comments for author
I enjoyed this paper a great deal. It told the story of ELISP and how it changed and evolved over time…driven by the needs of Emacs, of the open source community, of different views of development environments and tools (like debuggers and operating systems). It treats the language design, performance optimizations, surround features/environemnts as parts of the “whole” and I really like that approach. The personalities involved, especially the influence of Stallman, comes through - which is nice for an open source project that doesnt have the usual corporate funding/management issues that Jean Sammet used to ask about in earlier HOPLs.
the history up the present day and even hints at future plans…a natural thing to do, but probably not right for a history paper. There are a few obvious typos to that will have to be fixed.===========================================================================
Overall merit
- Accept
Reviewer expertise
- Knowledgeable
Paper summary
This paper describes the evolution of emacs lisp, from its very beginnings to the present day. The paper describes design and implementation changes, along with much of the background motivation and underlying politics.
Comments for author
I found this very interesting and overall an informative and enjoyable read. I enjoyed your writing style and the touches of humor. I enjoyed hearing the background to various technical decisions and some of the politics that under pinned the decisions.
I have only two suggestions
### Summary
summarizing some of the key elements of the story and highlights of the journey, in the form of a high-level re-cap.
### Lessons
I think there are quite a few lessons for language developers here. It may be worth drawing them out as such. This could be done in-place, or it could be done by including a list of lessons in the summary section. I am thinking here about lessons at all levels: open source software culture and how it affects the development and evolution of the language; the extent to which engineering pragmatics ultimately impact language design; the roles or personalities; the overall impact of the XEmacs split. Etc.
- I liked your point (p11) about the chicken-and-eggs nature of the TOC problem. I think this is a very common pattern in systems implementation.
- Your comment (p21) about the limited impact of optimizations where the underlying byte-code interpreter is slow, is interesting and probably common to many language implementations.
### Minor
- It would help your reviewers if you could include line numbers on the page (a feature which comes with the latest style files). This makes it very easy for us to precisely communicate references to the text.
Stefan - p6 “Richard Stallman felt” it would be great if you could provide references to such comments (I understand that this may not be possible).
- CLOSING NOTE [2019-08-19 lun 20:49]
Added citation
- CLOSING NOTE [2019-08-19 lun 20:52]
Explained the use of RCS in more details and the problem with CVS
transition is interesting, but needs a little bit more information. The reader may not understand that RCS required local operation, while CVS did not. Its not clear why the necessary files could not be kept around in CVS, nor how the original bootstrap began (answer on next page—the interpreter).
- p12 “heap size” this term is used widely to mean the size of the heap (how much memory is available to or consumed by the whole heap). However, here you mean something like the heap footprint of a given object. Sometimes in the GC literature, the word ‘cell’ is used to describe the space taken up by an object (inclusive of metadata etc). systemic).
- CLOSING NOTE [2019-08-19 lun 20:55]
Replaced “affect” with “speed up” to clarify
- CLOSING NOTE [2019-05-26 dim 01:49]
I found a mailing-list post about it and added its URL
By and large, the paper appears in relatively good shape. The authors have done a reasonable job of disentangling a complex history of two intertwined developments.
- CLOSING NOTE [2020-02-11 mar 13:32]
Explained the change in numbering
- CLOSING NOTE [2020-02-11 mar 13:52]
Made the timeline more precise
- CLOSING NOTE [2020-02-11 mar 14:03]
Rewrote the explanation to make it hopefully more clear
- CLOSING NOTE [2020-02-11 mar 14:10]
Changed the example to be more concrete here, indeed
It is obvious to you, but not to the reader.
- CLOSING NOTE [2020-02-11 mar 14:14]
Used the term “body” instead of “code” to clarify
(about …) or (with-elisp-eval-region …)?
- CLOSING NOTE [2020-02-11 mar 14:22]
Reworked the after/before explanation to try and clarify
- CLOSING NOTE [2020-02-11 mar 14:27]
Yes, 30-bit pointers. Made it explicit
If this is correct, best to say so explicitly; if not, I have misunderstood and you need to rewrite.
(to clarify the connection to 64 bits) They don’t have that much in common, and it would parallel breaking GC over sections 5.5-5.7, rather than having a single section on GC.- CLOSING NOTE [2020-02-11 mar 14:31]
Hmm… \texttt{mmap}ped looks odd to me, but it’s probably better, indeed
- CLOSING NOTE [2020-02-11 mar 14:36]
Made it more explicit
- CLOSING NOTE [2020-02-11 mar 14:38]
Made it explicit
“This” should only be used when it refers to an immediately preceding noun phrase, which here it does not. Rephrase.
- CLOSING NOTE [2020-02-11 mar 14:57]
Reminded the reader that 19.15 was released after 20.0
What does this mean? How does this differ from just shipping with XEmacs 19.15?
- CLOSING NOTE [2020-02-11 mar 15:11]
Added a description of the meaning of the :type example
I have no idea of what the given :type means or what documentation it might supplant.
- CLOSING NOTE [2020-02-11 mar 15:44]
We added a (sub)section on macros and mention that they are not hygienic
so possibly a few words on hygiene (or lack of it?) in Emacs Lisp macros is in order.
- Note taken on [2020-02-11 mar 17:52]
Stef says: I’ve fixed it to the point were it’s consistently inconsistent: “-” used with Emacs, and ” ” used for XEmacs and Lucid Emacs (except in the timeline where I kept “Emacs NN.MM”) I generally much prefer “Emacs-NN.MM” but it admittedly doesn’t work for Lucid Emacs and you seem to prefer “XEmacs NN.MM”, so maybe we should go with “Emacs NN.MM” tho I think we should be careful to use a non-breaking space then.
- CLOSING NOTE [2020-02-11 mar 15:51]
Reworked to clarify that the standard code was adjusted
while still using the standard macro-expansion code.” What does this mean? Are the features in cl-lib.el given new names? Or something else?
- CLOSING NOTE [2020-02-11 mar 15:54]
Thanks
- CLOSING NOTE [2020-02-11 mar 15:56]
Clarified a bit
If the latter, who?
- CLOSING NOTE [2020-02-11 mar 16:05]
Changed example accordingly
rather than a message.
- Note taken on [2020-02-18 mar 14:35]
I added the cl-typep example, along with some brief description of what happens with it. Please double check that it’s understandable (although there’s clearly not enough room to explain the details of what happens. I don’t even know how to clearly describe the semantics of define-inline (which is why it’s still basically undocumented :-( ))
Perhaps an example of how it is used to define cl-typep would help.
I rewrote a little bit.
- CLOSING NOTE [2020-02-11 mar 16:21]
Added examples of extra features supported by Names
Overall, I found the paper much improved after the shepherding process. In particular, I appreciate that the authors interviewed several early implementors of the language; this new material significantly strengthens the story.
Furthermore, the reorganization along topics works very well as it keeps similar discussion together. At the same time, the addition of the timeline on page 7 helps readers keep the overall chronology straight.
I found the paragraph that contains this sentence in the new conclusion intriguing: “What would have to be a language addition in many other languages is often just a library in Emacs Lisp.” I think the earlier parts of the text could say this more clearly up-front. In particular, what is remarkable about Emacs Lisp is that it has existed in such as consistent state over 30 years. Because of this comment, I wish the earlier parts of the discussion made stronger distinctions between what were changes to the language semantics (such as lexical scoping) and what were changes to the libraries (common lisp support, generators).
Minor comments and typos:
Is this deliberate? (Also this line is a bit different than the others, as it talks about a version in development not the most recently released version.) Not in the original; deleted.- CLOSING NOTE [2020-02-11 mar 16:27]
Rewritten to clarify
- CLOSING NOTE [2020-02-11 mar 16:29]
Reworded to clarify
- CLOSING NOTE [2020-02-11 mar 16:39]
Indeed, that’s when we use \texttt instead of \verb! Huh! Should be fixed now.
neither of the quotes used earlier. There is something weird going on with the font.
- CLOSING NOTE [2020-02-11 mar 16:46]
Reworded to clarify that the problem was not in fixing the code but in getting the users to replace the old package with the newer one
If not, why?
- CLOSING NOTE [2020-02-11 mar 16:49]
Reworded to try and clarify
Did any code ever do this?
- CLOSING NOTE [2020-02-11 mar 17:12]
Yes, clarified
The paper has improved greatly by its revisions. The story is clearer and compelling. thanks for the insights.
This is a great story, and well told. Thank you.
My high-level comments on this draft are that I think it reads well and captures the story well, with a nice balance between the technical and the sociological and between the domain-specific lessons and lessons that are broader.
I only have minor comments / corrections to make at this stage. You’ve done a great job. Below I refer to the line numbers in the draft I reviewed.
[611] I believe there are typos here in reference to the example code: “MAKE-CONS” -> “MAKE-KONS”, “CONS” -> “KONS”.
- CLOSING NOTE [2020-02-11 mar 17:14]
Indeed, thanks
- CLOSING NOTE [2020-02-11 mar 17:19]
We tried to use “(Section 6.1)” consistently
You may wish to check a style guide on this, but I suggest either make it non-parenthetical -> “as discussed in Section 6.1.” or explicitly parenthetical -> “(Section 6.1)”. You should settle on a style and apply it consistently. See for example [1128].
- Note taken on [2020-02-11 mar 17:26]
Stef says: In those bit-size and word size discussions, I tend to do a bit of trivial arithmetic in my head, and in that case I typically prefer the number over the word.
Some style guides suggest spelling out numbers when they arise in prose and have a single word in English, so “6” -> “six”, “2 words of header” -> “two words of header”. This is a minor issue, but you may wish to consider it, and if so apply the style consistently.
Mike agrees.
- CLOSING NOTE [2020-02-11 mar 17:32]
Indeed, the wording suggested it was a typo, clarified
but on [1110] the text suggests it was a write barrier. You may want to check this.
- Note taken on [2020-02-11 mar 17:36]
Stef notes: really? “all the” here seems better to me
Mike: Really.
[1695] I didn’t know Emacsen was a word. I do [now](https://www.emacswiki.org/emacs/Emacsen)!
- CLOSING NOTE [2020-02-11 mar 17:42]
Clarified
[1913] “the way it sounds” I suspect rather, it’s a because of the comic reference to the nursery rhyme.
- CLOSING NOTE [2020-02-11 mar 17:43]
That’s what we meant, thanks
[2092] “that buffers’s contents” -> “that the buffer’s contents” (or plural “that the contents of the buffers”)
- copyright waiver
http://history.acm.org/content.php?do=publicdocuments%20
- don’t write questions, write topics
- 3 sessions
- birth to grad school, then speed towards anecdotes
- slow down, contextualize, probe
- biggest regret
- let interviewee edit
- “mask”
- bring documents
- trust and collaboration
- iteration
- different settings - # of interviewees
- career interview vs. focused interview
- first general questions, then follow-up more specific
although, to be honest, for the histories I’ve done for the Computer History Museum, my experience is simply
– study the subject thoroughly before starting – listen, but follow up – listen again – keep listening
Here are things that maybe we’d like to know:
- how was Emacs’s development organized before Emacs-21
“Guy Steele designed the original symmetrical Emacs command set; then he and I began implementing Emacs (on top of TECO), but after one long joint development session, Steele began drifting away, so I finished Emacs.”
Actually, everything Mike was going to ask is answered here, and we can cite Seibel’s book:
http://www.classiccmp.org/pipermail/cctalk/2015-August/010369.html
Peter Siebel’s “Coders at Work” features a chapter/interview with Steele:
Siebel: During your time at MIT you were somehow involved in the birth
of Emacs. But the early history of Emacs is a hit hazy. What is your
version of the story?
Steele: My version of the story was that I was playing standards guy. What had happened was there was this display mode that turned TECO into something like a WYSIWYG editor. On our 24x80 screens, 21 lines of what was in the buffer would be shown on the screen and the bottom 3 lines were still a TECO command line. You’d be typing in these TECO commands and only when you hit the double altmode would they then be executed. Then there was the real-time edit mode, where it was suggested that a TECO command throw you in this other mode whereby instead of waiting for you to type the double altmode, TECO would react immediately to single character commands. If you type one character, it would do the command. You type another character, it would do the command. And most printing characters were self-inserting. Then the control characters were used to move forward, back, up, and down. It was a very, very primitive—it looked like a very primitive version of Emacs.
Then came the breakthrough. The suggestion was, we have this idea of taking a character and looking it up in a table and executing TECO commands. Why don’t we apply that to real-time edit mode? So that every character you can type is used as a lookup character in this table. And the default table says, printing characters are self-inserting and control characters do these things. But let’s just make it programmable and see what happens. And what immediately happened was four or five different bright people around MIT had their own ideas about what to do with that. Within just a few months there were five completely incompatible GUI interfaces to TECO.
Seibel: So they were just customizing, essentially, the key-bindings?
Steele: That’s right. And they each had their own ideas about what should be concise because you do it most often and what you can afford to be longer. So one guy, for example, was really concerned about typing in Lisp code and began to experiment with finding balanced parenthesized expressions. And another guy was more interested in text, so he was interested in commands that would move over words and convert between uppercase and lowercase and capitalize them. And that’s where those commands in Emacs came from.
Different people had different ideas about how the key-bindings ought to be organized. As a systems-support guy for Lisp, I was often called to people’s terminals and asked to help them. And I fairly quickly noticed that I couldn’t sit down at their TECOs and help them modify their programs because I’d be faced with a set of key-bindings and I had no idea what they were going to do.
Seibel: Was one of those guys Richard Stallman?
Steele: No, Stallman was the implementer and supporter of TECO. And he provided the built-in real-time edit mode feature, although I think Carl Mikkelsen had worked on the early version of it. He provided the key-bindings feature that made all of this possible.
Anyway, there were something like four different macro packages and they were incompatible, and I decided to play standards guy, or community reconciliation guy. I saw something that had been lost in our community, which was the ability to easily help each other at our terminals. I said, “OK, we’ve had some experimentation; we’ve seen a bunch of ideas. What if we could agree on a common set of key-bindings and draw the best ideas from each of these things?”
I literally had a pad of paper and ran around the building, talking to these guys, visiting each of them several times, and tried to get some kind of consensus. I was trying to get consensus on what the content ought to be and then I drew on their designs and tried to organize the actual choice of key-bindings so as to make them a little more regular and a little more mnemonic. And not being a human-factors guy at all, I didn’t think at all about convenience for touch typists. I was principally concerned with mnemonic value. And so that’s why Meta-C and Meta-L and Meta-U stand for capitalize and lowercase and uppercase.
…
Seibel: So you made this standard set of key-bindings. How did that go over? Were people happy with it?
Steele: Well, people worked through it. Then I sat down and proceeded to begin an implementation of it. And we had another idea that came into the mix at the same time and it was the idea that you could make TECO macros run a lot faster if you squeezed out the spaces and deleted all the comments. The way the TECO interpreter worked, interpreting one character at a time, when you encountered a comment it had to spend the time skipping over that comment. So we had this idea of this very primitive TECO compiler that was mostly just squeezing out the white space and the comments and doing a few other minor things to put it in a form that would run a little bit faster.
So I began in an initial way to try to construct a version of this macro compressor, which I think was actually based on an earlier idea that Moon had had. I don’t think I originated that idea. I began to think about how to organize the initial dispatch and organize some of the first few routines borrowing on the existing implementations of other macro pckages—I was trying to synthesize them. And about that point Stallman came along and said, “What are you doing? This looks interesting.” He immediately jumped in and he could implement ten times as fast as I could, partly because he knew TECO inside out.
So I worked seriously on the implementation of Emacs probably for only about four or six weeks. At which point it became clear that Stallman understood what the program was. I wanted to get back to doing graduate-student things. So Stallman did the other 99.999 percent of the work. But I played a role in catalyzing it and beginning the implementation.
Reading the accounts by Richard Stallman, Jamie Zawinski, and Richard Gabriel, one gets the impression that multiple opposing forces were pulling at you, not just into different political directions, but also into different technical ones. Can you describe what they were?
https://www.linkedin.com/in/joseph-arceneaux-1b1b20/
Hardly at all. From the answer to the next question you will see that we needed a server-based system with database, surrounded by tools that interacted with the server via protocols. Among the tools were text editors. Emacs was our favorite given that we were all MIT-centric Lisp people. I can’t recall whether it already existed or whether it was created for us, but LGPL was the way to do the connection. My strong recollection was that RMS created LGPL for us. I would need to see whether I can substantiate that with email. Remember that generally speaking RMS and I were friends.
Our “concession” was that we would fund Joe Arceneaux to make an X-based Emacs (Emacs 19) and supply an open-source version of Energize. Joe Arceneaux proved not up to the task, and RMS was slow responding and didn’t agree with some of our requirements for annotations - he believed people would create a few dozen per buffer, and we need programs to create thousands and very fast.
“Cadillac” project Lucid was working on, wasn’t originally planned with Emacs in mind as the editor component. (The way I read it, Emacs was part of the conception of the Hitchhiker project, which didn’t materialize.) How did Emacs get into the picture?
Patrick Dussud and I came up with the basic ideas in what became the Cadillac project over a period of a few months. However, unlike other software companies, our approach was to visit lots of organizations that did C++ programming to find out what they really did and really needed. Most companies in Lucid’s position would require NDAs from those companies interviewed; we didn’t. This set us apart. It was after about a year of these interviews that we came up with a server-based / kernel-based approach surround by tools. This because the interviewed really wanted to use their programmers’ favorite interactive tools and not ones we would write. That’s when Emacs came into the picture. These interviews changed a lot of our thinking.
fulfill that the time (apart from the lack of a windowed UI) - were any particular aspects of Emacs Lisp part of these requirements?
Please see the attached pdf file, which is the only paper we wrote about Energize. We needed the following:
- compilers that would annotate the source code with semantic information - we did not want to analyze the code ourselves and the interviewed did not want to see projections of ASTs. We chose GCC and we also bought a C++ compiler company and did our own. The annotations were designed to be language neutral (we did a quick prototype of a Fortran Energize, as I recall). This meant access to source code to add the annotation capabilities.
- a C++ database to hold the collected information about the software. This because we needed persistence, fast persistence, and the kernel had to be written in C++ to show that we believed in C++.
- graphic tools to show code structure. Debuggers (we used GDB, modifying it also).
- text editors that could respond to the Energize annotation protocols. Emacs had available source code, but not X-window support. Later we learned vi was essential, but we couldn’t get the source code, so we hacked on the vi mode of Emacs.
- all the protocols needed to work over TCP/IP. This meant that someone could work from home over a connection to the server running at their company. The tools (Emacs, graphics) would run at home; kernel, GCC, Lucid C++, and GDB could run at the company. To appreciate this, you should remember that Energize was designed and written in the late 1980s when such things as “over the net” were not a thing.
The annotations were like Nelson’s hypertext. HTML and all those were way in the future.
or problems with Emacs Lisp?
We wrote some stuff in Emacs Lisp, but mostly, as I recall, to establish the TCP/IP connections and the local connections to the kernel. Also to send reports to the kernel that the source code had been “damaged.” GDB’s display was through the kernel to Emacs.
support the front-end functionality. Given the number of annotations you were planning, how did performance of Emacs Lisp play into your planning and execution of Energize?
Wrong presumption.
We designed things so that the kernel did all the “thinking,” and Emacs had only to receive and display source code and annotations fed to it at interprocess communication speeds, and it had to handle thousands per buffer. The annotations had associated “pull-down menus,” which needed to be displayed, and selecting items therein were sent to the kernel which did them and sent back new “projections” of the code. Some in Emacs Lisp, as I recall, but the heavy lifting was in the C code for Emacs.
Emacs had to act like a hypertext system as well as a text editor. It was ok for Emacs’s modes to know about the language, but we didn’t care about that. The idea was that the tools (like Emacs) not know crap about the stuff they were presenting - all that was in the kernel.
I didn’t spend much time worrying about the Emacs Lisp part of it. Harlan Sexton and Jamie Zawinski were more in that loop.
In some message you suggested it was started in Sep 1984, IIRC, based on Gosling Emacs.
According to some reports, some time later Gosling sold Emacs to Unipress, and then a bit later, Unipress threatened you to stop using that code. So AFAIK the timeline looks like:
- Sep 1984: start work on GNU Emacs based on Gosling Emacs
- later Gosling sells his code to Unipress
- later Unipress threatens you
- then you rewrite the remaining pieces
Yet, according to https://www.reddit.com/r/emacs/comments/bek5b2/til_emacs_was_originally_written_by_james_gosling/ Unipress was already selling Gosling Emacs by Aug 1984.
Can you clarify the timeline? Was it that Unipress already had the right to sell Gosling Emacs but did not yet own the code? Or is that reddit post just confused about something?
Or that you actually started before Sep 1984?