HOPL IV: History of Programming Languages – Accepted Papers

The Papers track of HOPL-IV will include published papers that will be complemented by oral presentations at the conference. The Program Committee encourages submissions that discuss and analyze the historical development of individual programming languages, programming language families, language features, design themes, and other strong influences on the direction of programming language design, implementation, and usage.

Detailed information is listed on separate pages. Click on either the tabs above or the links in the list below.

• Prospective authors should read theCall for Papers, theContent Guidelines, and the Manuscript Preparation Guidelines .

• As authors prepare submissions, they should consult one or more of the sets of Questions for Authors (which are described by theContent Guidelines). These are intended to help authors who are addressing theEarly History of a specific language, laterEvolution of a specific language, a cross-language examination of a specificFeature or Concept, or aClass of Languages having a common theme or purpose.

• Both authors and prospective attendees may be interested in theHistory of HOPL, which includes links to the ACM Digital Library for all papers from prior HOPL conferences.

Call for Papers

For HOPL-IV the Program Committee encourages submissions that discuss and analyze the historical development of individual programming languages, programming language families, language features, design themes, and other strong influences on the direction of programming language design, implementation, and usage. A HOPL-IV paper that is about a single specific language should detail the early history or evolution of that language and the motivation for creating that new language; ideas about the language should have been documented by 2009, and the language should have been widely used by 2011. A HOPL-IV paper that addresses a language or language family already described in a previous HOPL conference should provide substantial new detail about language evolution, development and standardization activities, new dialects and implementations, significant publications, applications, user groups, and other technical and social consequences. A HOPL-IV paper about a more general historical theme or trend should take a cross-language perspective to discuss and analyze some issue or design feature that has affected the historical development of programming language design, implementation, and usage over a span of at least twenty years.

The Program Committee will work closely with prospective authors to ensure that both the content and presentation of the papers are of high quality. There will be two rounds of careful reviewing. The first round will select the papers for the conference (conditional acceptance); the second round will polish the papers and ensure that they meet the requirements for technical accuracy, historical completeness, and clarity. The Program Chairs may also ask outside experts to provide additional reviews. For each selected paper, a member of the Program Committee will be assigned as a “shepherd” to ensure that intermediate drafts are carefully revised and written clearly, and that the recommendations of reviewers are addressed.

Complete Author Guidelines and Instructionshave now been posted.

• Prospective authors should read theContent Guidelines and the Manuscript Preparation Guidelines .

• As authors prepare submissions, they should consult one or more of the sets of Questions for Authors (which are described by theContent Guidelines). These are intended to help authors who are addressing theEarly History of a specific language, laterEvolution of a specific language, a cross-language examination of a specificFeature or Concept, or aClass of Languages having a common theme or purpose.

• Another resource for authors is theHistory of HOPL, which includes links to the ACM Digital Library for all papers from prior HOPL conferences.

Authors may also find it useful to read two documents that provide guidelines for the program committee:

• HOPL IV Reviewing Principles , a guide for reviewers of HOPL papers, with comments on how HOPL differs from other SIGPLAN conferences

• HOPL Shepherding, a guide for program committee members serving as shepherds

Because of the complex nature of the history of programming languages, there is no upper bound on the length of submitted papers—authors should strive for completeness. We strongly recommend that prospective authors examine papers presented at previous HOPL conferences to get an idea of appropriate length, content, and organization. The website http://research.ihost.com/hopl has information about past HOPL conferences and links to their proceedings.

Papers awaiting acceptance to any other conference or journal are not eligible for submission to HOPL-IV. If a closely related paper has been submitted elsewhere, the HOPL-IV chairs must be notified. Authors of accepted papers are expected to make presentations (to be recorded in video form) at the conference. Final papers and video recordings of the presentations will be placed in the ACM Digital Library.

Program committee member policy: There will be no restriction on submissions from PC members. The program chairs/general chairs may not submit papers. PC papers will be held to a higher standard than other papers. The criterion for acceptability of a PC paper is a clear accept.

Submissions website: Abstracts and then full papers should be entered at the HOPL IV submissions website at hopl4.hotcrp.com . The abstract must be entered by the submission deadline for abstracts, but the PDF file for the first draft of the full paper does not have to be uploaded until the submission deadline for full papers. A submission may be initiated at any time and updated multiple times before the submission deadline; only the version in the system when the deadline passes will be examined by the committee.

Authors should submit a 1-page abstract by July 31, 2018. Full papers for the first round are due on August 31, 2018, with notification to authors in February 2019. Second-round submissions will be due in August 2019, with notification to authors in January 2020. Final copy will be due in March 2020. Authors of accepted papers will be required to sign ACM copyright release forms.

Inquiriesmay be sent by email tohopl4@sigplan.org.

List of Accepted Papers

Papers are listed in alphabetical order of language name.

This order does not reflect the order of presentation at the conference.

APL Since 1978

Roger K.W. Hui, Morten J. Kromberg

Thriving in a crowded and changing world: C++ 2006-2020

Bjarne Stroustrup

A History of Clojure

Rich Hickey

History of Coarrays and SPMD Parallelism in Fortran

John Reid, Bill Long, Jon Steidel

Origins of the D Programming Language

Walter Bright, Andrei Alexandrescu, Michael Parker

Evolution of Emacs Lisp

Stefan Monnier, Michael Sperber

The Early History of F#

Don Syme

A history of the Groovy programming language

Paul King

JavaScript: The First 20 Years

Allen Wirfs-Brock, Brendan Eich

LabVIEW

Jeff Kodosky

History of Logo

Cynthia Solomon, Brian Silverman, Henry Lieberman, Ken Kahn,

Brian Harvey, Mark L. Miller, Margaret Minsky, Artemis Papert

Hygienic Macro Technology

William D Clinger, Mitchell Wand

A History of MATLAB

Jack Little, Cleve Moler

The Origins of Objective-C at PPI/Stepstone and its Evolution at NeXT

Brad Cox, Steve Naroff, Hansen Hsu

A history of the Oz multiparadigm language

Peter Van Roy, Seif Haridi, Christian Schulte, Gert Smolka

S, R and Data Science.

John Chambers

The Evolution of Smalltalk from Smalltalk-72 through Squeak

Daniel Ingalls

The History of Standard ML

David MacQueen, Robert Harper, John Reppy

Verilog HDL and its ancestors and descendants

Peter Flake, Phil Moorby, Steve Golson, Arturo Salz, Simon Davidmann

History of HOPL

HOPL has been held only infrequently; the first three were in 1978, 1993, and 2007. HOPL-IV is scheduled for June 2020.

The first History of Programming Language Conference (now also called HOPL-I) was held in 1978. [ ACM website ; historical website ] The program chair, Jean Sammet, established the general format and rigorous reviewing criteria that have been followed ever since. (Sammet was also the author of the book Programming Languages: History and Fundamentals , an encylopedic survey of programming languages as of 1969.)

Each HOPL-I paper discussed the development and evolution of a computer programming language, the people who participated in that work, and the context in which it was undertaken. A separate brief technical summary of each presented language was also prepared, either by the authors of the corresponding paper or by a separate invited expert. For each paper there was an oral presentation at the conference, followed by a relatively lengthy question-and-answer session, both of which were transcribed and published. Papers on these languages were presented at HOPL-I:

The HOPL-I proceedings were also published as a book , edited by Richard Wexelblat.

HOPL-II, held in 1993, was also chaired by Jean Sammet. [ ACM website ; historical website ] Some papers addressed concepts and/or language families rather than single languages. As for HOPL-I, a separate brief technical summary of each presented language was also prepared, either by the authors of the corresponding paper or by separate invited experts. Papers on these fourteen topics were presented at HOPL-II:

The HOPL-II proceedings were also published as a book , edited by Thomas Bergin and Richard Gibson. (The transcripts of the presentations and discussion appear only in the book, not on the ACM website.)

In 2007, HOPL-III was chaired by Barbara Ryder and Brent Hailpern, with Jean Sammet on the program committee. [ ACM website ; historical website ] For this conference, all oral sessions were videotaped. The twelve papers at HOPL-III described thirteen languages:

The HOPL-III conference also included the retrospective multimedia keynote presentation 50 in 50 (also reprised at Yow! 2010 and viewable here ).

Manuscript Preparation Guidelines for Authors

Submission Preparation Instructions

Deadlines: The deadline for submission of an initial one-page abstract is Tuesday, July 31, 2018, Anywhere on Earth . A full paper submission must be added by Friday, August 31, 2018, Anywhere on Earth . These deadlines will be strictly enforced.

Submission: Submissions will be accepted through a web interface at https://hopl4.hotcrp.com . To avoid last-minute problems, authors are encouraged to create a hotcrp account and a HOPL-IV submission page for their submission well ahead of July 31, 2018 (which is the deadline for abstracts).

Improved versions of an abstract may be submitted at any time before the abstract submission deadline using the same web interface. Similarly, improved versions of a full paper may be submitted at any time before the full paper submission deadline. In each case, the last version submitted before the deadline will be the version reviewed.

Paper format: Submissions must be in PDF format, printable in black and white on both US Letter sized and A4 sized paper, and interpretable by common PDF tools. All submissions should adhere as closely as possible to the “ACM Small” template that is available (in both LaTeX and Word formats) from http://www.acm.org/publications/authors/submissions . This is a single-column page layout with a 10-point font, 12-point line spacing, and wide margins: the main text block is 5.478 inches (13.91 cm) wide and 7.884 inches (20.03 cm) tall. For authors using LaTeX, the use of the review option is also strongly encouraged but not required. (The review option will add line numbers, which will make it easier for reviewers to reference specific parts of your paper in their comments, but should have absolutely no other effect on the typesetting.)

Because of the complex nature of the history of programming languages, there is no upper bound on the length of submitted papers—authors should strive for completeness. The Program Committee strongly recommends that prospective authors examine papers presented at previous HOPL conferences to get an idea of appropriate length, content, and organization. For more information, see the Content Guidelines for Authors .

Citation format: HOPL-IV papers are expected to use author-year citations for references to other work. Author-year citations may be used as either a noun phrase:

The lambda calculus was originally conceived by Church (1932).

or a parenthetic phrase:

The lambda calculus (Church 1932) was intended as a foundation for mathematics.

A useful test for correct usage is to make sure that the text still reads correctly when the parenthesized portions of any references are omitted. Take care with prepositions; in the first example above, “by” is more appropriate than “in” because it allows the text to be read correctly as a reference to the author.

In LaTeX, use \citet to get a citation in the form of a noun phrase and \citep to get a citation in the form of a parenthetic phrase:

\citet{Church-1932} produces “Church (1932)”

\citep{Church-1932} produces “(Church 1932)”

For details, see Sections 2.3 through 2.5 of the natbib documentation ( http://ctan.org/pkg/natbib ).

Authorship Policies: All submissions are expected to comply with the ACM Policies for Authorship .

Republication Policies: Papers must be unpublished work that is not currently submitted for publication elsewhere as described by SIGPLAN’s Republication Policy . Submitters should also be aware of ACM’s Policy and Procedures on Plagiarism .

Final Publication and Copyright Requirements

Because of the long lead time for the HOPL conference, the precise formatting requirements for the final versions of papers to be published have not yet been determined.

Authors of accepted papers will be required to choose one of the following publication rights:

1. Author licenses the work with a Creative Commons license , retains copyright, and (implicitly) grants ACM non-exclusive permission to publish ( suggested choice ).
2. Author retains copyright of the work and grants ACM a non-exclusive permission-to-publish license.
3. Author retains copyright of the work and grants ACM an exclusive permission-to-publish license.
4. Author transfers copyright of the work to ACM.

These choices follow from ACM Copyright Policy and ACM Author Rights , corresponding to ACM’s “author pays” option.

Presentation Requirements

On-the-record in-person presentation and discussion of papers is an important part of the HOPL conference format. At least one author of each accepted submission will be expected to attend and present their paper at the conference. (HOPL-IV welcomes all authors, regardless of nationality. In the extreme case that authors are unable despite reasonable effort to obtain visas to travel to the conference, efforts will be made to enable remote participation. In such cases, the HOPL-IV chairs should be contacted (email:hopl4@sigplan.org) for guidance.)

The schedule for presentations will be determined and shared with authors after the full program has been selected.

Each presentation will consist of a long talk (likely 45 minutes or longer), to be followed by a question-and-answer session, according to the conference schedule. HOPL-IV presentations and associated question-and-answer sessions will be videorecorded and released online.

A paper may be presented at the conference only if (i) all authors of the paper have signed a copyright form to permit publication by ACM under one of the allowed copyright options, (ii) at least one author of the paper is registered to attend the conference, and (iii) all presenters have signed a consent form to permit videotaping and online publication of the presentation.

Content Guidelines for Authors

The first three History of Programming Languages conferences established high technical and editorial standards. We trust that your contribution will help HOPL-IV maintain or surpass these standards. These guidelines are intended to help you develop the appropriate content for your contribution to HOPL-IV.

Appropriate Languages

The criteria for the programming languages considered appropriate for HOPL-IV are:

(1) The programming language came into existence before 2009, that is, it was designed and described at least 11 years before HOPL-IV (2020).
(2a) The programming language has been widely used since 2011 either (i) commercially or (ii) within a specific domain. In either case, “widely used” implies use beyond its creators.
(2b) Certain research languages had great influence on widely used languages that followed them. If the research language was used by more than its own inventors, and the paper clearly traces its influence on other languages in wider use, then it may be considered appropriate for discussion at HOPL-IV.

Please be sure to include within your paper a clear indication of how the subject material satisfies these criteria—not only (1), but also either (2a)(i) or (2a)(ii) or (2b). This information can certainly be provided indirectly as part of the overall text. For instance, some of the criteria are dates; it suffices to include the dates as part of the historical narrative.

Categories of Submissions

There are four kinds of papers that may be considered for HOPL-IV:

• Early History of a specific language, typically including the story of its initial design and first implementation(s)

• Later Evolution of a specific language (usually a language already treated in an earlier HOPL conference)

• A cross-language examination of a specific Feature or Concept

• Consideration of a Class of Languages having a common theme or purpose

These categories overlap to some extent; for example, Evolution of a single initial language may result in a Class of Languages that share some Feature or Concept. It is not necessary to label your submission as belonging to a specific category; rather, the categories are intended as a tool to help you organize the story you want to tell and to make sure that relevant information is not overlooked.

Questions for Authors

For each category we provide a set of questions that you should consider when writing your paper (to see them, click on the links in the list shown above). The questions point to the kind of information that people want to know about the history of programming languages. The four sets of questions overlap to some extent; even within a single set, the same question, or very similar questions, may be asked in different contexts. Please draft your paper in light of these different emphases and contexts. It may be appropriate for you to examine more than one set of questions. Conversely, keep in mind that there may be important aspects of your specific story that the questions fail to address.

Your paper should try to answer as many questions as possible, but it is understood that you might not be able to address every one of them. Because history can unfold in so many different ways, some of the questions may be clearly irrelevant to your particular topic, or your particular point of view. The information requested might no longer be available, but please remember that the very fact of unavailability may be important to report as well. Several questions are of the form “How did something affect something else?”; it may be important for the historical record to assert that “it didn’t.”

A question set is intended to suggest the content, not the form, of your paper. (In particular, your paper should not be in question-answer format!) The questions are organized into topics and subtopics for your convenience during your research; this structure is not meant to serve as an outline for your paper. (Topics, subtopics, and questions are also numbered and lettered for convenience of reference.) Please feel free to use whatever form and style for your paper seems most appropriate and comfortable to you.

We recommend that you read two pages of advice from Michael S. Mahoney about What Makes History? . This will help you to adopt an appropriate historical perspective when writing.

The Program Committee strongly suggests that you examine at least one paper from each of the proceedings of HOPL-I, HOPL-II, and HOPL-III to see what earlier contributors did. Links to all prior HOPL papers (within the ACM Digital Library) may be foundhere. We also suggest here examples of papers in each category:

• Early History: COBOL or FORTRAN or LISP or ALGOL 68 or Erlang or Haskell or High Performance Fortran (HPF)

• Evolution: Evolution of Lisp

• Feature or Concept: Monitors and Concurrent Pascal

• Class of Languages: Discrete Event Simulation Languages

Questions for Authors: Early History

Please see the Content Guidelines for Authors for detailed instructions on how to use this set of questions.

The principal objective of a contribution in this category is to record the history of the origins, early development, and initial deployment of a single programming language.

These questions are directed primarily to the origins of the project and to the people involved and how they were organized.

1. Motivation

   (a) What (or who) was the real origin of the idea to develop this language? (This question may have more than one good answer; the choice may shape the perspective of your paper. Be sure to consider whether there are multiple perspectives.)

   (b) Who was the prime mover for the development effort?

   (c) What was the primary motivation in developing the language (e.g., research, task assigned by management)?

   (d) Did the motivation change over time before the language was released? After the language was released?

2. Languages and Systems Known at the Time

   (a) What other specific languages were known to you and/or other members of the development group at the time the work started? Which other languages did any of you learn about as the work progressed? Was such learning in intentional pursuit of information to guide the design or development of the new language? How much did you know about these languages and in what ways (e.g., as users, from having read unpublished and/or published papers, informal conversations, from documentation, from reading the code for the implementation, from having participated in the design or implementation)? Please try to distinguish between what you, the author, knew at the time and what the other members of the project knew at the time.

   (b) Were these other languages regarded as formal inputs to consider in your own language development, or did they merely provide background? What was it about these languages that you wanted to emulate (e.g., syntax, capabilities, internal structure, application area, etc.)?

   (c) How influenced were you by these languages? Put another way, how much did the prior language backgrounds of you and other members of the group influence the early language design? Whether the answer is “a lot” or “a little,” why did these other languages have that level of influence?

   (d) Was there a primary source of inspiration for the language, and if so, what was it? Was the language modeled after this (or any other predecessors or prototypes)?

   (e) How did information about each of these other languages or systems become available to the people it influenced?

   (f) Were any specific new features borrowed from, inspired by, or created as an alternative to specific features in other languages or systems? Why?

   (g) Were any proposed or plausible features omitted or removed in response to experience with other languages or systems? Why?

   (h) Was the design, development, or deployment process modeled on that used for another language or system? Why?

   (i) Was the design, development, or deployment process intentionally done differently from that used for another language or system? Why?

3. Basic Facts about Activities, Organization, and People

   (a) Under what organizational auspices (if any) was the language developed (e.g., name of company, department/division in the company, university, consortium or collaboration, open-source project, standardization effort)? Be as specific as possible about organizational units and subunits involved.

   (b) What, if any, was the nature of any cooperation or competition among multiple organizations or organizational subunits?

   (c) Were there problems or conflicts within the organization(s) in getting the project started? If so, please indicate what these were and how they were resolved.

   (d) What was the source of funding (e.g., research grant, company R&D, company production units, government contract)?

   (e) Who were the people on the project and what was their relationship to the author(s) (e.g., team members, subordinates, managers)? To the largest extent possible, name all the people involved, including part-timers, when each person joined the project, and what each person worked on and when. Indicate the technical experience and background of each participant, including formal education. Please be as specific as possible regarding names, titles, and dates.

   (f) How did the roles of various individuals change during the course of the activity?

   (g) In what ways did geographic factors affect what was done, who participated, how they were organized, and how they communicated?

   (h) In what ways did organizational or political factors affect what was done, who participated, how they were organized, and how they communicated?

   (i) In what ways did computerized or networked facilities affect what was done, who participated, how they were organized, and how they communicated?

   (j) In what ways did the availability (or lack) of other resources affect what was done, who participated, how they were organized, and how they communicated?

   (k) Were the design and implementation done together, by a single person or team? Alternatively, were there separate design and implementation steps or phases, and if so, were the design and the implementation done by the same people or different (possibly overlapping) teams?

   (l) Was the design done originally as a research project, as a development project, as a committee effort, as an open-source effort, as a one-person effort with some minor assistance, or what? Was it a side effect of some other effort that happened to produce a language as a subgoal, but the language itself ended up being important in its own right?

   (m) Was the implementation done originally as a research project, as a development project, as a committee effort, as an open-source effort, as a one-person effort with some minor assistance, or what?

   (n) Was there a separate documentation team, or was documentation written by designers and/or implementors?

   (o) Was testing (“quality assurance”) done by a separate team? By the designers or implementors?

   (p) Were there any persons whose roles were “marketing” or “user liaison” or “user training”? If so, who fulfilled such roles, and how?

   (q) Was there a defined leader to the group? If so, what was his or her exact position (and title) and how did he or she get to be the leader (e.g., appointed “from above”, self-starter, volunteer, elected)?

   (r) Was there a de facto leader different from the defined leader? If so, who was this leader and what made this person the de facto leader (personality, background, experience, a “higher authority”, something else)? Was one person the “manager” and another the “technical lead”? Or did more than one person fill either or these roles? Was technical leadership divided according to multiple design or implementation areas?

   (s) Were there consultants from outside the project who had a formal connection to it? If so, who were they, how and why were they chosen, and how much help were they? Were there also informal consultants? If so, please answer the same questions.

   (t) Did the participants in the project view themselves primarily as language designers, as implementors, or as eventual users? If there were some of each working on the project, indicate the split as much as possible. How did this internal view of the people involved affect the initial planning and organization of the project?

   (u) Did the language designers know (or believe) that they would also have the responsibility for implementing the first version? Whether the answer is “yes” or “no”, was the technical language design affected by this?

   (v) Did the language designers know (or believe) that they would also have the responsibility for maintaining subsequent versions? Whether the answer is “yes” or “no”, was the technical language design affected by this?

4. Costs and Schedules

   (a) Was there a budget? Was it adequate? Did the budget provide a fixed upper limit on the costs? If so, how much money was to be allocated and in what ways? What external or internal factors led to the budget constraints? Was the money formally divided between language design and actual implementation? If so, in what way?

   (b) Was there a fixed deadline for completion of the project? Was the project divided into phases and did these have deadlines? How well were the deadlines met?

   (c) What is the best estimate for the amount of human resources involved (i.e., in person-years)? How much was for language design, for documentation, for implementation, and for other functions?

   (d) What is the best estimate of the costs prior to putting the first system in the hands of the first users? If possible, show as much breakdown on this as possible.

   (e) If there were cost and/or schedule constraints, how did that affect the language design and in what ways?

   (f) What other resource constraints affected the schedule?

   (g) Did any external constraints (such as customer requirements or competition with another organization) influence the schedule?

5. Basic Facts about Documentation

   (a) What are the significant publications that arose from design, development, testing, and deployment? For each provide:

   • (a1) Full bibliographic citation

   • (a2) Names of authors (if not part of the reference)

   • (a3) Intended audience (e.g., user, implementer, language researcher)

   • (a4) Format (e.g., manual, general trade book, standards document, conference paper, web page, blog entry)

   • (a5) Availability

   (b) In the planning stage, was there consideration of the need for documentation of the work as it progressed? If so, was it for internal communication among project members or external monitoring of the project by others, or both?

   (c) What types of documentation were decided upon?

   (d) Did any sort of intentional specification precede implementation, or was an initial implementation followed by documentation?

   (e) If documentation and implementation were found to be in conflict, was one generally considered more definitive than the other? If so, which one, and why? Did this change over time?

   (f) Was a test suite developed to verify the implementation? If so, was it used to perform regression tests on the compiler or other parts of the implementation? Was the test suite made public? To what extent was the test suite considered part of the (internal or external) specification or documentation?

   (g) To the largest extent possible, cite both dates and documents for the following (including internal papers and web sites which may not have been released outside of the project) by title, date, and author.

   • (g1) Initial idea

   • (g2) First documentation of initial idea

   • (g3) Preliminary specifications

   • (g4) “Final” specifications (i.e., those which were intended to be implemented)

   • (g5) “Prototype” running (i.e., as thoroughly debugged as the state of the art permitted, but perhaps not all of the features included)

   • (g6) “Full” language compiler (or interpreter) was running

   • (g7) Usage on real problems done by the developers

   • (g8) Usage on real problems done by people other than the developers

   • (g9) Documentation by formal methods

   • (g10) Paper(s) in professional journals or conference proceedings

   • (g11) Please identify extensions, modifications and new versions

   • (g12) Independent implementations by other groups or organizations

   For each of these stages, where relevant, indicate the level of formality of the specifications. Were specifications entirely in prose (in English or some other “natural language”), or were any formalisms used (examples include BNF, regular expressions or other ways of marking optional or repeated elements in the syntax, syntax diagrams (aka “railway charts”), attribute grammars, mathematical equations, algebraic specifications, denotational semantics, the Vienna definition language, compiler-construction tools such as parser generators, and proof assistants)? Were the formalisms directed primarily to the explanation of syntax, or was formalism also used in the explanation of semantics (that is, program behavior)?

   (h) If there were independent implementations, did they rely entirely on specifications and documentation, or did they read or borrow from an existing code base and/or communicate directly with the original development team?

   (i) Please reflect on the project documents as historical sources. Throughout your paper, identify when you are relying on these documents for information, and when you are relying on memory or other sources. Are there places where memory and documentation conflict? Do you now regard the available documentation as a complete and faithful record of the history, or can you identify gaps or incorrect information in the documents?

   (j) It may be appropriate to reproduce a limited number of original documents or photographs in your paper. Which ones are the most relevant for telling the story?

6. Intended Purposes and Users

   (a) For what application area was the language designed? What type of problems was it intended to be used for? Traditional labels such as “business data processing” or “scientific applications” may be too vague; please be as specific as possible and appropriate in describing the application area.

   • (a1) Was a specific statement of application area or purpose drafted when the project started? If so, did it change over the course of the project?

   • (a2) Was the apparent application area of some other language used as a model?

   (b) For what types of users was the language intended (e.g., experienced programmers, mathematicians, business people, novice programmers, non-programmers)? Was there any conflict within the group on this? Were compromises made, and if so, were they made for technical or non-technical reasons?

   (c) Why develop a new language? Why were existing languages deemed sufficiently inadequate for the purpose that a new effort was justified?

   • (c1) Was the design developed from whole cloth in response to the stated application area or purpose?

   • (c2) Was the intent to create a language “just like language X, except for thus-and-so specific improvements”?

   • (c3) Was the intent to create a synthesis of the best ideas from two or more other languages?

   • (c4) Was the language created in order to exemplify or promulgate a specific theoretical idea?

   • (c5) Was the language initially the result of “just hacking around”, perhaps by grafting a new idea or two onto an existing language?

   (d) How much of the language design effort went into application-specific features, and how much of it went into “structural issues” or “software engineering issues” such as modularity, namespace management, debugging support, or features coders of libraries might need as opposed to application programmers?

   (e) What equipment was the language originally intended to be implemented on? Wherever possible, cite specific machine(s) by manufacturer(s) and model numbers, or alternatively, give broad descriptions relevant to the time period with specific examples. Consider this example from the HOPL-I paper about COBOL:

   COBOL was designed from its inception to be used on large computers (by 1959 standards, although by 1978 standards they would be considered minicomputers), intended for business data processing use. In particular, machines for which COBOL was certainly being considered were the UNIVAC I and II, the IBM 705 and 709, the Honeywell 800, RCA 501, Sylvania MOBIDIC, [and] Burroughs B-5000.
   

   Was machine independence a significant design goal, albeit within this class of machines?

7. Distribution

   (a) Was the language specification (information needed to create a complete implementation) made available to users? Was it considered proprietary? Was it provided for free or for sale? What distribution media were used?

   (b) How was the language implementation made available to users? Was it considered proprietary? Was it provided for free, for lease or subscription, or for sale? What distribution media were used? Were users able to run it on their own hardware, or only as part of a service on hardware they did not own?

   (c) How was the language documentation (information needed to use the language, which may or may not include the specification and may or may not include tutorial material) made available to users? Was it considered proprietary? Was it provided for free or for sale? What distribution media were used?

   (d) Did the answers to any of the preceding questions change over time?

II. RATIONALE OF THE CONTENT OF THE LANGUAGE

These questions are directed to the technical content of the language design and implementation effort and are intended to stimulate thought about various factors that affect most language design effort. Not all the questions are relevant for every language. They are intended to suggest areas that might be addressed in each paper. This is not necessarily an exhaustive list of relevant questions.

1. Environmental Factors

   To what extent was the design of the language influenced by:

   (a) Program Size: Was it explicitly thought that programs written in the language would be large and/or written by more than one programmer? Or, conversely, was it explicitly thought that typical programs would be small and/or written primarily by one programmer? What features were explicitly included (or excluded) for this reason? If this factor wasn’t considered, did it turn out to be a mistake? Were specific tools or development environments designed at the same time to support these choices?

   (b) Program Libraries and/or Frameworks: Were “program libraries” (or “standard frameworks”) envisioned as necessary or desirable, and if so, how much provision was made for them? Were “standard libraries” a major portion of the language design effort? If so, what libraries were especially important? Which libraries were novel, unusual, or essential to the “flavor” of the language? Alternatively, was it an important design goal of the language to be able to interoperate with existing libraries already coded in another language?

   (c) Portability: How important was the goal of machine independence? What features reflect concern for portability? How well was this goal attained?

   (d) User Background and Training: What features catered to the expected background of intended users?

   • (d1) Were any notational or semantic features of the language intentionally modeled on notations or semantics not widely used in computer science but customary in an intended domain of application?

   • (d2) How difficult did it prove to train users in the correct and effective use of the language, and was the difficulty a surprise? What changes in the language would have alleviated training problems? Were any proposed features rejected because it was felt users would not be able to use them correctly or appropriately?

   • (d3) In retrospect, what features of the language proved to be difficult for programmers to use correctly? Did some features fall into disuse? Please identify such features and explain why they fell into disuse.

   (e) Execution Efficiency: How did requirements for executable code size and speed affect the language design? Were programs in the language expected to execute on large or small computers (i.e., was the size of object programs and/or execution speed expected to pose a problem)? What design decisions were explicitly motivated by the concern (or lack of concern) for execution efficiency? Did these concerns turn out to be accurate? How was the design of specific features changed to make it easier to optimize executable code?

   (f) Target Computer Architecture: To what extent were features in the language dictated by the characteristics of the anticipated target computer (e.g., word size, floating-point hardware, instruction set peculiarities, application-specific instructions, register or cache structure, special-purpose co-processors and accelerators, parallelism, synchronization features, transactional memory)? Were there multiple targets, and if so, in wha way did this affect the language design or implementation?

   (g) Compilation Environment: To what extent, if any, did concerns about compilation efficiency affect the design? Were features rejected or included primarily to make it easier to implement compilers for the language or to ensure that the compiler(s) would execute quickly? In retrospect, how correct or incorrect do you feel these decisions were? What decisions did you make regarding use of the compiler run-time system?

   (h) Programming Ease: To what extent was the ease of coding an important consideration and what features in the language reflect the relative importance of this goal? Did maintainability considerations affect any design decisions? If so, which ones?

   (i) Execution Environment: To what extent did the language design reflect its anticipated use in a batch, timeshared, embedded, portable, mobile, wearable, kiosk, office, or networked environment? What features reflect these concerns?

   (j) Multiple Implementations: Were there multiple implementations being developed at the same time as the later part of the language development? If so, was the language design hampered, improved, or influenced by this in any way?

   (k) Standardization: In addition to (or possibly separate from) the issue of portability, what considerations were given to possible standardization? What types of standardization were considered, and what groups were involved and when?

   (l) Networking/Parallel Environment: To what extent did the language design reflect its anticipated use in a networked- or parallel-execution environment? What features reflect these concerns? Was execution efficiency in a networked or parallel environment (as opposed to single-CPU efficiency) a concern?

   (m) Interoperability: Was it important for programs written in this language to interoperate with code written in other languages, operating systems, or other tools? If so, which ones, and why? Did this require specific technical features in the new language?

   (n) Documentation: Were features included to specifically to support documentation of programs coded in the language? If so, did they support documentation tied to the program representation, generation of separate documents (paper documents, files, web pages), or both? What tools and conventions were used or supported?

   (o) Reliability: Were features included specifically to support detection or prevention of programming errors and/or proofs of program correctness? Were otherwise common or familiar features omitted in order to help prevent programming errors?

   (p) Debugging: Were features included specifically to support the debugging process?

2. Functions to be Programmed

   (a) How did the operations and data types in the language support the writing of particular kinds of algorithms or applications?

   (b) What features might have been left out, if a slightly different application area had been in mind?

   (c) What features were considered essential to properly express the kinds of programs to be written?

   (d) What misconceptions about application requirements turned up that necessitated redesign of application-specific features before the language was actually released?

   (e) To what extent were application-specific features incorporated directly into the language design, and to what extent was the expectation that application-specific features would be provided (perhaps as libraries) by coding in the language itself? Were any features of the language specifically intended to support or enable the latter?

3. Language Design Principles

   (a) What consideration, if any, was given to designing the language so that programming errors could be detected early and easily? Were the problems of debugging and testing considered? Were debugging and testing facilities deliberately included in the language?

   (b) To what extent was the goal of keeping the language simple considered important? What kind of simplicity was considered most important? What did your group mean by “simplicity”? Was there an explicit statement of simplicity that guided the design effort?

   (c) To what extent was the goal of keeping the language consistent considered important? What kind of consistency was considered most important? What did your group mean by “consistency”? Was there an explicit statement of consistency that guided the design effort?

   (d) Were there any other explicitly stated principles that guided the language design? If so, were any specific proposed features modified or omitted after coming into conflict with a stated principle?

   (e) What thought was given to make programs more understandable and how did these considerations influence the design? Was there conscious consideration of making programs “easy to read” versus “easy to write”? If so, which were chosen and why?

   (f) Did you consciously develop the data types first and then the operations, or did you use the opposite order, or did you try to develop both in parallel with appropriate iteration? Were data and operations combined into objects?

   (g) To what extent did the design reflect a conscious philosophy of how languages should be designed (or how programs should be developed)? What was this philosophy?

   (h) Did you intentionally model the language according to an existing style or school of thought (e.g., Algol-like, Lisp-like, macro-like, imperative, declarative, block-structured, object-oriented, functional, pure, or stack-based)? If so, why? In what ways does your resulting design reflect this style or school of thought, and in what ways does it differ, and why?

   (i) Were any slogans or catchphrases used as summaries or reminders of language design principles? Were they used internally or also externally? Were they used seriously or jocularly?

   (j) Did the developers of the language make any attempt to evaluate specific features, or the entire language design, objectively/empirically? Did the results lead to changes in the language design? Did such changes result in programs that were somehow better (e.g., shorter, more reliable, more efficient, easier to read, easier to maintain)?

4. Language Specification

   (a) What techniques for specifying languages were known to you? Did you use these or modify them, or did you develop new ones?

   (b) To what extent (if any) was the language itself influenced by the technique used for the specification?

   (c) What formalisms and/or tools were used in the specification process?

5. Concepts About Other Languages

   (a) Were you consciously trying to introduce new concepts? If so, what were they? Do you feel that you succeeded? (Conversely, was it a design goal to avoid introducing new concepts? If so, why?)

   (b) If you were not trying to introduce new concepts, what was the justification for introducing this new language? (Such justification might involve technical, personal, political, or economic factors.)

   (c) To what extent did the design consciously borrow from previous language designs or attempt to correct perceived mistakes in other languages?

6. Influence of Non-technical Factors

   (a) How did time and cost constraints (as described in the Background section) influence the technical design?

   (b) How did the size and structure of the design group affect the technical design?

   (c) How did the size and structure of the implementation group affect the implementation?

   (d) How did the size and structure of the documentation group affect the documentation?

   (e) Did the membership of any of these groups change over time, and if so, how did such changes affect the design, implementation, or documentation efforts?

   (f) Provide any other information you have pertaining to ways in which the technical language design was influenced or affected by non-technical factors.

III. A POSTERIORI EVALUATION

These questions are directed to assessing the language project from today’s standpoint.

1. Meeting of Objectives

   (a) How well do you think the language met its original objectives?

   (b) What is the size and nature of the current user community? Do the users think the language has met its objectives? Do the users think the language has met their needs? If not, what do users think could be done, or should have been done, to further improve the language?

   (c) How well do you think the computing community (as a whole) thinks the objectives were met?

   (d) How much impact did portability (i.e., machine independence) have on acceptance by users?

   (e) How much impact did other specific aspects of the language (such as execution efficiency, compilation efficiency, ease of programming, or specific libraries) have on acceptance by users?

   (f) Did the objectives change over time? If so, how, when, why, and in what ways did they change?

   (g) Was the language eventually put to unexpected uses, or adopted by an unexpected user community? If so, what were the results? Did the language change further in response to these new uses? How might the language or even the initial objectives have been different if these uses had originally been anticipated?

2. Contributions of Language

   (a) What is the major contribution that was made by this language? Was this one of the objectives? Was this contribution a technical or a non-technical contribution, or both? What other important contributions are made by this language? Were these part of the defined objectives? Were these contributions technical or non-technical?

   (b) What do you consider the best points of the language, even if they are not considered to be a contribution to the field (i.e., what are you proudest of, regardless of what anybody else thinks)?

   (c) Are there now multiple independent implementations of the language?

   (d) What other people or groups decided to implement this language because of its inherent value?

   (e) Did this language have any effect (positive or negative) on the development of later hardware?

   (f) Did this language have any effect (positive or negative) on the development of later languages? Have specific innovative features of this language appeared in later languages?

   (g) Did this language spawn any “dialects”? If so, please identify them. Were they major or minor changes to the language definition? How significant did the dialects themselves become? Describe the resulting “family tree” of both languages and development communities.

   (h) In what way do you feel the computer field is better off (or worse) for having this language?

   (i) What fundamental effects on the future of language design resulted from this language development (e.g., theoretical discoveries, new data types, new control structures)?

3. Mistakes or Desired Changes

   (a) What mistakes do you think were made in the design of the language? Why do you consider them to be mistakes? Were any of these able to be corrected in a later version of the language? If you feel several mistakes were made, list as many as possible with some indication of the severity of each.

   (b) Even if not considered mistakes, what changes would you make if you could do it all over again?

   (c) What have been the biggest changes made to the language (possibly by people other than the original development team) since its early development? Were these changes or new capabilities considered originally and omitted in the initial development, or were they truly later thoughts? If they were originally considered and omitted, why were they omitted (e.g., desire for simplicity, consistency with overarching design principles, time or other resource constraints)? Were they omitted with the intent to reconsider them later?

   (d) Have changes been suggested but not adopted? If so, be as explicit as possible about changes suggested, and why they were not adopted.

4. Problems

   (a) What were the biggest problems you had during the language design process? Did these affect the end result significantly?

   (b) What are the biggest problems the users have had?

   (c) What are the biggest problems the implementors have had? Were these deliberate, in the sense that a conscious decision was made to do something in the language design, even if it made the implementation more difficult?

   (d) What are the biggest problems the documenters of the language have had? Would the language have been easier to document or to explain to users if the language had been designed differently?

   (e) What trade-offs did you consciously make during the language design process? What trade-offs did you unconsciously make?

   (f) What compromises did you have to make to meet other constraints such as time, budget, user demands, political, or other factors?

IV. IMPLICATIONS FOR CURRENT AND FUTURE LANGUAGES

These questions are directed to the ways in which your language or language project might affect its successors.

1. Direct Influence

   (a) Have other, more recent language designs been directly influenced by this one? Have other languages borrowed specific features, implementation techniques, specification techniques, documentation techniques, debugging techniques, or proof techniques from this language effort? Has any other language had interoperability with this language as one of its design goals?

   (b) What language developments of today and the foreseeable future are being directly influenced by your language? Regardless of whether your answer is “none” or “just these few …” or “many, such as …”, please indicate the reasons.

   (c) Is there anything in the experience of your language development which should influence current and future languages? If so, what is it? Put another way, in light of your experience, do you have advice for current and future language designers? What are the important lessons learned from the development of this language? What are the important lessons from the user experience?

   (d) Does your language have a long-range future? Regardless of whether your answer is “yes” or “no”, please indicate the reasons.

2. Indirect Influence

   (a) Are there indirect influences which your language is having now?

   (b) Are there any indirect influences that it can be expected to have in the near future? What are these, and why do you think they will be influential?

Questions for Authors: Language Evolution

Please see the Content Guidelines for Authors for detailed instructions on how to use this set of questions.

The principal objective of a contribution in this category is to treat the history of a major language subsequent to its original development. This may entail extending the history of some language whose origins were treated in an earlier HOPL conference.

When a programming language is first developed, it is typically the work of an individual or a small, concentrated group. Later development of a language is often the result of an expanded, re-staffed group, and perhaps additional individuals or groups outside the original organization. Similarly, while original work is often focused on language design and implementation for a single environment, later developments may be undertaken in a broader arena.

When compared with questions about the early history of a language, the following questions reflect this change in context. In particular, these questions address the set of diverse development activities that may surround the language, such as standardization, new implementations, significant publications, and language-oriented groups of persons (such as ACM SIGs, user groups, and open-source communities). However, many of the questions here are similar or identical to those in the “early history” questions, as noted below.

These questions are grouped into the same four broad categories that apply to papers on the early history of a language:

(1) Background

  (2) Rationale of content

  (3) A posteriori evaluation

  (4) Implications for current and future languages

The very first question applies broadly and is intended to identify the particular development activities that are the focus of the history paper. All subsequent questions, in all sections, should be considered for each of the activities identified in response to that first question.

You may also have significant new information to contribute regarding early history of the language, especially if such information is relevant to subsequent developments. If so, be sure to place such material in appropriate context, and carefully distinguish new information about early history from the history of subsequent development.

Where appropriate, your contribution should make reference to related papers from earlier HOPL conferences.

0. Categories of Development and Activities

   What triggered the developments reported on, and what major development activities resulted?

   (Examples of development activities are standardization, forking of specifications or implementations, creation of new implementations from specifications, research activities, creation of products from research prototypes, release as open source, significant publications such as specifications or tutorials, creation of formal or informal user groups, borrowing or adaptation from other languages, and creation or further development of competing languages. Note that activities may serve as triggers for other activities; for example, user requirements or requests might trigger standardization activities, which in turn might trigger new implementation activities. Similarly, release of open source or an unencumbered specification might trigger new implementation activity.)

From this point on, each question is intended to apply independently to each development activity identified by the preceding question. However, in the actual paper, it may be appropriate to group or consolidate answers that apply to multiple such activities.

1. Motivation

   Questions I.1(a)–(d) correspond to those in the “early history questions” Section I.1.

   (a) What (or who) was the real origin of the idea to further develop this language? (This question may have more than one good answer; the choice may shape the perspective of your paper. Be sure to consider whether there are multiple perspectives.)

   (b) Who was the prime mover for the evolutionary development effort?

   (c) What was the primary motivation to further develop the language (e.g., research, task assigned by management, turn a research prototype into a product, attract new users)?

   (d) Did the motivation change over time before the revised or further developed language was released? After the language was released?

   In addition:

   (e) In what ways did these motivations differ from the motivations for the original creation or development of the language?

2. Languages or Systems Known at the Time

   Questions I.2(a)–(i) correspond to those in the “early history questions” Section I.2.

   (a) What other specific languages were known to you and/or other members of the development group at the time the work started? Which other languages did any of you learn about as the evolutionary work progressed? Was such learning in intentional pursuit of information to guide the evolutionary design or development of the new language? How much did you know about these languages and in what ways (e.g., as users, from having read unpublished and/or published papers, informal conversations, from documentation, from reading the code for the implementation, from having participated in the design or implementation)? Please try to distinguish between what you, the author, knew at the time and what the other members of the project knew at the time.

   (b) Were these other languages regarded as formal inputs to consider in your own language development, or did they merely provide background? What was it about these languages that you wanted to emulate (e.g., syntax, capabilities, internal structure, application area, etc.)?

   (c) How influenced were you by these languages? Put another way, how much did the prior language backgrounds of you and other members of the group influence the early language design? Whether the answer is “a lot” or “a little,” why did these other languages have that level of influence?

   (d) Was there a primary source of inspiration for further language development, and if so, what was it? Were specific evolutionary changes to the language modeled after this (or any other predecessors or prototypes)?

   (e) How did information about each of these other languages or systems become available to the people it influenced?

   (f) Were any specific new features borrowed from, inspired by, or created as an alternative to specific features in other languages or systems? Why?

   (g) Were any proposed or plausible features omitted or removed in response to experience with other languages or systems? Why?

   (h) Was the design, development, or deployment process modeled on that used for another language or system? Why?

   (i) Was the design, development, or deployment process intentionally done differently from that used for another language or system? Why?

   In addition:

   (j) Was the design, development, or deployment process intentionally done differently from that used during the early history of this language because of experience with another language or system?

3. Basic Facts About Activities, Organizations, and People

   Questions I.3(a)–(v) correspond to those in the “early history questions” Section I.3.

   (a) Under what organizational auspices (if any) was the language further developed (e.g., name of company, department/division in the company, university, consortium or collaboration, open-source project, standardization effort)? Be as specific as possible about organizational units and subunits involved.

   (b) What, if any, was the nature of any cooperation or competition among multiple organizations or organizational subunits?

   (c) Were there problems or conflicts within the organization(s) in getting the project started? If so, please indicate what these were and how they were resolved.

   (d) What was the source of funding (e.g., research grant, company R&D, company production units, government contract)?

   (e) Who were the people on the project and what was their relationship to the author(s) (e.g., team members, subordinates, managers)? To the largest extent possible, name all the people involved, including part-timers, when each person joined the project, and what each person worked on and when. Indicate the technical experience and background of each participant, including formal education. Please be as specific as possible regarding names, titles, and dates.

   (f) How did the roles of various individuals change during the course of the activity?

   (g) In what ways did geographic factors affect what was done, who participated, how they were organized, and how they communicated?

   (h) In what ways did organizational or political factors affect what was done, who participated, how they were organized, and how they communicated?

   (i) In what ways did computerized or networked facilities affect what was done, who participated, how they were organized, and how they communicated?

   (j) In what ways did the availability (or lack) of other resources affect what was done, who participated, how they were organized, and how they communicated?

   (k) Were the design and implementation done together, by a single person or team? Alternatively, were there separate design and implementation steps or phases, and if so, were the design and the implementation done by the same people or different (possibly overlapping) teams?

   (l) Was the evolutionary development done originally as a research project, as a development project, as a committee effort, as an open-source effort, as a one-person effort with some minor assistance, or what? Was it a side effect of some other effort that happened to produce a revised language or implementation as a subgoal, but the language or implementation itself ended up being important in its own right?

   (m) Was the implementation done originally as a research project, as a development project, as a committee effort, as an open-source effort, as a one-person effort with some minor assistance, or what?

   (n) Was there a separate documentation team, or was documentation written by designers and/or implementors?

   (o) Was testing (“quality assurance”) done by a separate team? By the designers or implementors?

   (p) Were there any persons whose roles were “marketing” or “user liaison” or “user training”? If so, who fulfilled such roles, and how?

   (q) Was there a defined leader to the group? If so, what was his or her exact position (and title) and how did he or she get to be the leader (e.g., appointed “from above”, self-starter, volunteer, elected)?

   (r) Was there a de facto leader different from the defined leader? If so, who was this leader and what made this person the de facto leader (personality, background, experience, a “higher authority”, something else)? Was one person the “manager” and another the “technical lead”? Or did more than one person fill either or these roles? Was technical leadership divided according to multiple design or implementation areas?

   (s) Were there consultants from outside the project who had a formal connection to it? If so, who were they, how and why were they chosen, and how much help were they? Were there also informal consultants? If so, please answer the same questions.

   (t) Did the participants in the project view themselves primarily as language designers, as implementors, or as eventual users? If there were some of each working on the project, indicate the split as much as possible. How did this internal view of the people involved affect the initial planning and organization of the project?

   (u) Did the language designers know (or believe) that they would also have the responsibility for implementing the revised language? Whether the answer is “yes” or “no”, was the technical language design affected by this?

   (v) Did the language designers know (or believe) that they would also have the responsibility for maintaining subsequent versions? Whether the answer is “yes” or “no”, was the technical language design affected by this?

   In addition:

   (w) How were the organizations involved in evolutionary developments related to the organizations that originally developed the language?

   (x) How were the people involved in evolutionary developments related organizationally to the original developers for this language?

4. Costs and Schedules

   Questions I.4(a)–(g) correspond to those in the “early history questions” Section I.4.

   (a) Was there a budget? Was it adequate? Did the budget provide a fixed upper limit on the costs? If so, how much money was to be allocated and in what ways? What external or internal factors led to the budget constraints? Was the money formally divided between language design and actual implementation? If so, in what way?

   (b) Was there a fixed deadline for completion of the project? Was the project divided into phases and did these have deadlines? How well were the deadlines met?

   (c) What is the best estimate for the amount of human resources involved (i.e., in person-years)? How much was for language design, for documentation, for implementation, and for other functions?

   (d) What is the best estimate of the costs prior to putting the first system in the hands of the first users? If possible, show as much breakdown on this as possible.

   (e) If there were cost and/or schedule constraints, how did that affect the language design and in what ways?

   (f) What other resource constraints affected the schedule?

   (g) Did any external constraints (such as customer requirements or competition with another organization) influence the schedule?

5. Basic Facts about Documentation

   Questions I.5(a)–(j) correspond to those in the “early history questions” Section I.5.

   (a) What are the significant publications that arose from design, development, testing, and deployment? For each provide:

   • (a1) Full bibliographic citation

   • (a2) Names of authors (if not part of the reference)

   • (a3) Intended audience (e.g., user, implementer, language researcher)

   • (a4) Format (e.g., manual, general trade book, standards document, conference paper, web page, blog entry)

   • (a5) Availability

   (b) In the planning stage, was there consideration of the need for documentation of the work as it progressed? If so, was it for internal communication among project members or external monitoring of the project by others, or both?

   (c) What types of documentation were decided upon?

   (d) Did any sort of intentional specification precede implementation, or was an initial implementation followed by documentation?

   (e) If documentation and implementation were found to be in conflict, was one generally considered more definitive than the other? If so, which one, and why? Did this change over time?

   (f) Was a test suite developed to verify the implementation? If so, was it used to perform regression tests on the compiler or other parts of the implementation? Was the test suite made public? To what extent was the test suite considered part of the (internal or external) specification or documentation?

   (g) To the largest extent possible, cite both dates and documents for the following (including internal papers and web sites which may not have been released outside of the project) by title, date, and author.

   • (g1) Initial idea

   • (g2) First documentation of initial idea

   • (g3) Preliminary specifications

   • (g4) “Final” specifications (i.e., those which were intended to be implemented)

   • (g5) “Prototype” running (i.e., as thoroughly debugged as the state of the art permitted, but perhaps not all of the features included)

   • (g6) “Full” language compiler (or interpreter) was running

   • (g7) Usage on real problems done by the developers

   • (g8) Usage on real problems done by people other than the developers

   • (g9) Documentation by formal methods

   • (g10) Paper(s) in professional journals or conference proceedings

   • (g11) Please identify extensions, modifications and new versions

   • (g12) Independent implementations by other groups or organizations

   For each of these stages, where relevant, indicate the level of formality of the specifications. Were specifications entirely in prose (in English or some other “natural language”), or were any formalisms used (examples include BNF, regular expressions or other ways of marking optional or repeated elements in the syntax, syntax diagrams (aka “railway charts”), attribute grammars, mathematical equations, algebraic specifications, denotational semantics, the Vienna definition language, compiler-construction tools such as parser generators, and proof assistants)? Were the formalisms directed primarily to the explanation of syntax, or was formalism also used in the explanation of semantics (that is, program behavior)?

   (h) If there were independent implementations, did they rely entirely on specifications and documentation, or did they read or borrow from an existing code base and/or communicate directly with the original development team?

   (i) Please reflect on the project documents as historical sources. Throughout your paper, identify when you are relying on these documents for information, and when you are relying on memory or other sources. Are there places where memory and documentation conflict? Do you now regard the available documentation as a complete and faithful record of the history, or can you identify gaps or incorrect information in the documents?

   (j) It may be appropriate to reproduce a limited number of original documents or photographs in your paper. Which ones are the most relevant for telling the story?

   In addition:

   (k) Which documents were revised or superseded as a result of the evolutionary development, and which documents were unchanged?

   (l) Was it a stated principle of (or constraint on) the evolutionary development that certain documents remain unchanged?

6. Intended Purposes and Users

   Questions I.6(a)–(e) correspond to those in the “early history questions” Section I.6.

   (a) For what application area were evolutionary changes to the language or its implementation intended? What different or additional types of problems was it intended to be used for? Traditional labels such as “business data processing” or “scientific applications” may be too vague; please be as specific as possible and appropriate in describing the application area.

   • (a1) Was a specific statement of application area or purpose drafted when the project started? If so, did it change over the course of the project?

   • (a2) Was the apparent application area of some other language used as a model?

   (b) For what types of users was the revised language intended (e.g., experienced programmers, mathematicians, business people, novice programmers, non-programmers)? Was there any conflict within the group on this? Were compromises made, and if so, were they made for technical or non-technical reasons?

   (c) Why revise the language? Why was the existing language, or other languages deemed sufficiently inadequate for the purpose that a new effort was justified?

   • (c1) Was the revisions developed specifically in response to a stated new application area or purpose?

   • (c2) Was the intent to create a language “just like the old one, except for thus-and-so specific incremental improvements”?

   • (c3) Was the intent to create a synthesis by incorporating ideas from other languages?

   • (c4) Was the language revised in order to exemplify or promulgate a specific theoretical idea?

   • (c5) Was the revision initially the result of “just hacking around”, perhaps by grafting a new idea or two onto the existing language?

   (d) How much of the language revision effort went into application-specific features, and how much of it went into “structural issues” or “software engineering issues” such as modularity, namespace management, debugging support, or features coders of libraries might need as opposed to application programmers?

   (e) Were revisions driven by the requirements of porting the language to new target architectures? Wherever possible, cite specific machine(s) by manufacturer(s) and model numbers, or alternatively, give broad descriptions relevant to the time period with specific examples.

   In addition:

   (f) How did the intended set of applications differ from the originally intended set of applications for this language?

   (g) How did the intended set of users differ from the originally intended set of users for this language?

   (h) Was increased machine independence a significant design goal of the language revision? Alternatively, was better access to or exploitation of machine-dependent facilities a significant design goal of the language revision?

7. Distribution

   Questions I.7(a)–(d) correspond to those in the “early history questions” Section I.7.

   (a) Was the revised language specification (information needed to create a complete implementation) made available to users? Was it considered proprietary? Was it provided for free or for sale? What distribution media were used?

   (b) How was the revised language implementation made available to users? Was it considered proprietary? Was it provided for free, for lease or subscription, or for sale? What distribution media were used? Were users able to run it on their own hardware, or only as part of a service on hardware they did not own?

   (c) How was the revised language documentation (information needed to use the language, which may or may not include the specification and may or may not include tutorial material) made available to users? Was it considered proprietary? Was it provided for free or for sale? What distribution media were used?

   (d) Did the answers to any of the preceding questions change over time?

II. RATIONALE OF THE CONTENT OF THE DEVELOPMENT

1. Environmental Factors

   Questions II.1(a)–(p) correspond to those in the “early history questions” Section II.1.

   To what extent was the revision of the language influenced by:

   (a) Program Size: Was it explicitly thought that programs written in the language would be large and/or written by more than one programmer? Or, conversely, was it explicitly thought that typical programs would be small and/or written primarily by one programmer? What features were explicitly included (or excluded) for this reason? If this factor wasn’t considered, did it turn out to be a mistake? Were specific tools or development environments designed at the same time to support these choices?

   (b) Program Libraries and/or Frameworks: Were “program libraries” (or “standard frameworks”) envisioned as necessary or desirable, and if so, how much provision was made for them? Were “standard libraries” a major portion of the language design effort? If so, what libraries were especially important? Which libraries were novel, unusual, or essential to the “flavor” of the language? Alternatively, was it an important design goal of the language to be able to interoperate with existing libraries already coded in another language?

   (c) Portability: How important was the goal of machine independence? What revisions reflect concern for portability? How well was this goal attained?

   (d) User Background and Training: What revisions catered to the expected background of intended users?

   • (d1) Were any notational or semantic features of the language intentionally modeled on notations or semantics not widely used in computer science but customary in an intended domain of application?

   • (d2) How difficult did it prove to train users in the correct and effective use of the language, and was the difficulty a surprise? What changes in the language would have alleviated training problems? Were any proposed features rejected because it was felt users would not be able to use them correctly or appropriately?

   • (d3) In retrospect, what features of the language proved to be difficult for programmers to use correctly? Did some features fall into disuse? Please identify such features and explain why they fell into disuse.

   (e) Execution Efficiency: How did requirements for executable code size and speed affect the language revision? Were programs in the language expected to execute on large or small computers (i.e., was the size of object programs and/or execution speed expected to pose a problem)? What design decisions were explicitly motivated by the concern (or lack of concern) for execution efficiency? Did these concerns turn out to be accurate? How was the design of specific features changed to make it easier to optimize executable code?

   (f) Target Computer Architecture: To what extent were revisions in the language dictated by the characteristics of the anticipated target computer (e.g., word size, floating-point hardware, instruction set peculiarities, application-specific instructions, register or cache structure, special-purpose co-processors and accelerators, parallelism, synchronization features, transactional memory)? Were there multiple targets, and if so, in wha way did this affect the language design or implementation?

   (g) Compilation Environment: To what extent, if any, did concerns about compilation efficiency affect the revision? Were features rejected or included primarily to make it easier to implement compilers for the language or to ensure that the compiler(s) would execute quickly? In retrospect, how correct or incorrect do you feel these decisions were? What decisions did you make regarding use of the compiler run-time system?

   (h) Programming Ease: To what extent was the ease of coding an important consideration and what revisions to the language reflect the relative importance of this goal? Did maintainability considerations affect any design decisions? If so, which ones?

   (i) Execution Environment: To what extent did the language design reflect its anticipated use in a batch, timeshared, embedded, portable, mobile, wearable, kiosk, office, or networked environment? What revisions reflect these concerns?

   (j) Multiple Implementations: Were there multiple implementations being developed at the same time as the later part of the language development? If so, was the language design hampered, improved, or influenced by this in any way?

   (k) Standardization: In addition to (or possibly separate from) the issue of portability, what considerations were given to possible standardization? What types of standardization were considered, and what groups were involved and when?

   (l) Networking/Parallel Environment: To what extent did the language revision reflect its anticipated use in a networked- or parallel-execution environment? What features reflect these concerns? Was execution efficiency in a networked or parallel environment (as opposed to single-CPU efficiency) a concern?

   (m) Interoperability: Was it important for programs written in this language to interoperate with code written in other languages, operating systems, or other tools? If so, which ones, and why? Did this require specific technical changes to the language?

   (n) Documentation: Were features included to specifically to support documentation of programs coded in the language? If so, did they support documentation tied to the program representation, generation of separate documents (paper documents, files, web pages), or both? What tools and conventions were used or supported?

   (o) Reliability: Were features included specifically to support detection or prevention of programming errors and/or proofs of program correctness? Were otherwise common or familiar features omitted in order to help prevent programming errors?

   (p) Debugging: Were features included specifically to support the debugging process?

   In addition:

   (q) In what ways had the environment changed since the original development of the language? In what ways did such changes motivate or influence new developments?

2. Functions to be Programmed

   Questions II.2(a)–(e) correspond to those in the “early history questions” Section II.2.

   (a) How did the operations and data types in the revised language support the writing of particular kinds of algorithms or applications?

   (b) What revisions might have been left out, if a slightly different application area had been in mind?

   (c) What revisions were considered essential to properly express the kinds of programs to be written?

   (d) What misconceptions about application requirements turned up that necessitated redesign of application-specific features before the revised language was actually released?

   (e) To what extent were application-specific features incorporated directly into the language design, and to what extent was the expectation that application-specific features would be provided (perhaps as libraries) by coding in the language itself? Were any features of the language specifically intended to support or enable the latter?

   In addition:

   (f) Was the language changed or extended in order to better support existing classes of applications or users?

   (g) Was the language changed or extended in order to support new classes of applications or users?

   (h) What features were considered essential to meet intended applications?

   (i) What features were considered “nice” or “convenient” but not essential?

   (j) Which changes were “upward compatible” and which were “incompatible”?

   (k) How were tradeoffs evaluated? Who evaluated the tradeoffs? Who made the decisions?

3. Language Design Principles

   Questions II.3(a)–(j) correspond to those in the “early history questions” Section II.3.

   (a) What consideration, if any, was given to revising the language so that programming errors could be detected earlier and more easily? Were the problems of debugging and testing considered? Were debugging and testing facilities deliberately included in the language?

   (b) To what extent was the goal of keeping the language simple considered important? What kind of simplicity was considered most important? What did your group mean by “simplicity”? Was there an explicit statement of simplicity that guided the revision effort?

   (c) To what extent was the goal of keeping the language consistent considered important? What kind of consistency was considered most important? What did your group mean by “consistency”? Was there an explicit statement of consistency that guided the revision effort?

   (d) Were there any other explicitly stated principles that guided the language revision? If so, were any specific proposed features modified or omitted after coming into conflict with a stated principle?

   (e) What thought was given to make programs more understandable and how did these considerations influence the design? Was there conscious consideration of making programs “easy to read” versus “easy to write”? If so, which were chosen and why?

   (f) Did you consciously develop the data types first and then the operations, or did you use the opposite order, or did you try to develop both in parallel with appropriate iteration? Were data and operations combined into objects?

   (g) To what extent did the revision reflect a conscious philosophy of how languages should be designed or revised (or how programs should be developed)? What was this philosophy?

   (h) Did you intentionally model the revised language according to an existing style or school of thought (e.g., Algol-like, Lisp-like, macro-like, imperative, declarative, block-structured, object-oriented, functional, pure, or stack-based)? If so, why? In what ways does your resulting design reflect this style or school of thought, and in what ways does it differ, and why?

   (i) Were any slogans or catchphrases used as summaries or reminders of language design principles? Were they used internally or also externally? Were they used seriously or jocularly?

   (j) Did the developers of the revised language make any attempt to evaluate specific features, or the entire language design, objectively/empirically? Did the results lead to changes in the language design? Did such changes result in programs that were somehow better (e.g., shorter, more reliable, more efficient, easier to read, easier to maintain)?

   In addition:

   (k) What language design principles from the original development were preserved? Of these, which were considered important?

   (l) What language design principles from the original development were intentionally modified, discarded, or replaced?

   (m) What language design principles from the original development were unintentionally violated, disrupted, negated, or abandoned?

   (n) Was it a stated principle of (or constraint on) the evolutionary design effort that certain code bases remain unchanged?

4. Language Specification

   Questions II.4(a)–(c) correspond to those in the “early history questions” Section II.4.

   (a) What techniques for specifying languages were known to you? Did you use these or modify them, or did you develop new ones?

   (b) To what extent (if any) was the revised language itself influenced by the technique used for the specification?

   (c) What formalisms and/or tools were used in the specification process?

   In addition:

   (d) What language specification principles, tools, and techniques were used in this new development? To what extent was the result of the development influenced by these choices?

   (e) Was the language specification revised to produce a single new comprehensive specification? Alternatively, was an incremental addendum produced?

   (f) What language specification principles, tools, or techniques from the original development were preserved? Of these, which were considered important?

   (g) What language specification principles, tools, or techniques from the original development were intentionally modified, discarded, or replaced?

   (h) What language specification principles, tools, or techniques from the original development were unintentionally violated, disrupted, negated, or abandoned?

5. Concepts about Other Languages

   Questions II.5(a)–(c) correspond to those in the “early history questions” Section II.5.

   (a) Were you consciously trying to introduce new concepts? If so, what were they? Do you feel that you succeeded? (Conversely, was it a design goal to avoid introducing new concepts? If so, why?)

   (b) If you were not trying to introduce new concepts, what was the justification for revising the language? (Such justification might involve technical, personal, political, or economic factors.)

   (c) To what extent did the design consciously borrow from previous language designs or attempt to correct perceived mistakes in other languages?

   In addition:

   (d) To what extent was the introduction of new language concepts or features a part (or an explicit goal) of this development?

   (e) To what extent was the development influenced by a perceived need to compete with other languages or other development efforts?

6. Influence of Non-technical Factors

   Questions II.6(a)–(f) correspond to those in the “early history questions” Section II.6.

   (a) How did time and cost constraints (as described in the Background section) influence the technical design?

   (b) How did the size and structure of the design group affect the technical design?

   (c) How did the size and structure of the implementation group affect the implementation?

   (d) How did the size and structure of the documentation group affect the documentation?

   (e) Did the membership of any of these groups change over time, and if so, how did such changes affect the design, implementation, or documentation efforts?

   (f) Provide any other information you have pertaining to ways in which the technical language design was influenced or affected by non-technical factors.

   In addition:

   (g) What non-technical factors were different for the new development as compared to the original language development?

   (h) How did differences or changes in non-technical factors affect the new development?

III. A POSTERIORI EVALUATION

Sections III.1–4 correspond to those in the “early history questions” Sections III.1–4.

These questions are directed to assessing the language project from today’s standpoint.

1. Meeting of Objectives

   (a) How well do you think the revised language met the original objectives for the revision?

   (b) What is the size and nature of the current user community? Do the users think the language has met its objectives? Do the users think the revised language has met their needs? If not, what do users think could be done, or should have been done, to further improve the language?

   (c) How well do you think the computing community (as a whole) thinks the objectives were met?

   (d) How much impact did portability (i.e., machine independence) have on acceptance by users?

   (e) How much impact did other specific aspects of the language (such as execution efficiency, compilation efficiency, ease of programming, or specific libraries) have on acceptance by users?

   (f) Did the objectives change over time? If so, how, when, why, and in what ways did they change?

   (g) Was the revised language eventually put to unexpected uses, or adopted by an unexpected user community? If so, what were the results? Did the language change further in response to these new uses? How might the language or even the initial objectives have been different if these uses had originally been anticipated?

2. Contributions of Language

   (a) What is the major contribution that was made by this language revision? Was this one of the objectives? Was this contribution a technical or a non-technical contribution, or both? What other important contributions are made by this language? Were these part of the defined objectives? Were these contributions technical or non-technical?

   (b) What do you consider the best points of the language, even if they are not considered to be a contribution to the field (i.e., what are you proudest of, regardless of what anybody else thinks)?

   (c) Are there now multiple independent implementations of the language?

   (d) What other people or groups decided to implement this revised language because of its inherent value?

   (e) Did this revised language have any effect (positive or negative) on the development of later hardware?

   (f) Did this revised language have any effect (positive or negative) on the development of later languages? Have specific innovative features of this revision appeared in later languages?

   (g) Did this language spawn any “dialects”? If so, please identify them. Were they major or minor changes to the language definition? How significant did the dialects themselves become? Describe the resulting “family tree” of both languages and development communities.

   (h) In what way do you feel the computer field is better off (or worse) for having this revised language?

   (i) What fundamental effects on the future of language design resulted from this language development (e.g., theoretical discoveries, new data types, new control structures)?

3. Mistakes or Desired Changes

   (a) What mistakes do you think were made in the revision of the language? Why do you consider them to be mistakes? Were any of these able to be corrected in a yet later version of the language? If you feel several mistakes were made, list as many as possible with some indication of the severity of each.

   (b) Even if not considered mistakes, what changes would you make if you could do it all over again?

   (c) What have been the biggest changes made to the language (possibly by people other than the original development team) since its early development? Were these changes or new capabilities considered originally and omitted in the initial development, or were they truly later thoughts? If they were originally considered and omitted, why were they omitted (e.g., desire for simplicity, consistency with overarching design principles, time or other resource constraints)? Were they omitted with the intent to reconsider them later?

   (d) Have changes been suggested but not adopted? If so, be as explicit as possible about changes suggested, and why they were not adopted.

4. Problems

   (a) What were the biggest problems you had during the language revision process? Did these affect the end result significantly?

   (b) What are the biggest problems the users have had?

   (c) What are the biggest problems the implementors have had? Were these deliberate, in the sense that a conscious decision was made to do something in the language design, even if it made the implementation more difficult?

   (d) What are the biggest problems the documenters of the language have had? Would the language have been easier to document or to explain to users if the language had been designed differently?

   (e) What trade-offs did you consciously make during the language design process? What trade-offs did you unconsciously make?

   (f) What compromises did you have to make to meet other constraints such as time, budget, user demands, political, or other factors?

In addition:

1. Supersession and Cohesion

   (a) Has the original version of the language been superseded, or do the original and revised versions coexist with a substantial set of users for each? Why?

   (b) Is there now a single revised version of the language, or has language evolution resulted in a diversity of dialects or incompatible implementations? Why?

IV. IMPLICATIONS FOR CURRENT AND FUTURE LANGUAGES

Sections IV.1–2 correspond to those in the “early history questions” Sections IV.1–2.

These questions are directed to the ways in which your language or language project might affect its successors.

1. Direct Influence

   (a) Have other, more recent language designs been directly influenced by this language revision? Have other languages borrowed specific features, implementation techniques, specification techniques, documentation techniques, debugging techniques, or proof techniques from this language effort? Has any other language had interoperability with this language as one of its design goals?

   (b) What language developments of today and the foreseeable future are being directly influenced by your language? Regardless of whether your answer is “none” or “just these few …” or “many, such as …”, please indicate the reasons.

   (c) Is there anything in the experience of your evolutionary language development which should influence current and future languages? If so, what is it? Put another way, in light of your experience, do you have advice for current and future language designers? What are the important lessons learned from the revision of this language? What are the important lessons from the user experience?

   (d) Does your language have a long-range future? Regardless of whether your answer is “yes” or “no”, please indicate the reasons.

2. Indirect Influence

   (a) Are there indirect influences which your language is having now?

   (b) Are there any indirect influences that it can be expected to have in the near future? What are these, and why do you think they will be influential?

Questions for Authors: Feature or Concept

Please see the Content Guidelines for Authors for detailed instructions on how to use this set of questions.

The principal objective of a contribution in this category is to record the history of a programming language feature or concept.

This question set has a quite different focus from the set dealing with the development of some particular language. A particular language feature or concept is incorporated in multiple particular languages; therefore much of the information solicited here is comparative. However, to the extent that you were party to the development of particular language(s) embodying this feature, it may be appropriate also to be guided by the Questions on the Early History of a [single] Language .

For simplicity, these questions usually refer to a “feature” rather than a “feature or concept.”

1. Origins

   (a) Who invented or introduced this feature? Was it a single person, a team, or a committee? What was their background? How did they come to use this background in their development?

   (b) What are the important publications (e.g., papers, language manuals) about the feature? Please make a special point of identifying as many early publications as possible, including informal and internal documents.

   (c) If the feature first appeared in a simpler or even “half-baked” form before the widespread form emerged, be sure to describe the early forms, with citations, and how and why they evolved. What factors caused the feature to reach a “definitive” form (e.g., perceived technical merit, feedback from early or prospective users, institutional pressures)?

   (d) Was the creation or implementation of the feature motivated more by theory or by practice?

   (e) Did the feature emerge as the result of a research project? A corporate or industrial project? A standardization process? “Just hacking around”?

   (f) Was there a stated rationale or set of goals for the feature?

   (g) Was there a stated set of design principles for the feature?

   (h) Was the feature first created especially for a single language (from it then presumably spread to other languages), or did its creator(s) originally have in mind a class of languages (e.g., Algol-like, functional, object-oriented, parallel)?

   (i) In which language(s) was this feature first introduced? Who introduced it? How did the people involved with it interact in the process, if more than one person was involved?

   (k) Was a new language created specifically to embody or exemplify this new feature, or was its first implementation or embodiment grafted into an existing language, or was it one of a number of innovations in a new language?

   (l) Please consult the Background section of Questions on the Early History of a Language for questions about project organization, project funding, documentation, and distribution.

2. The Nature of This Feature or Concept

   (a) What are the distinctive characteristics of this feature? Be sure to discuss both syntax and semantics, and what aspects are essential and which are nonessential.

   (b) Was the feature intended to express an idea previously very difficult or impossible to express in existing languages? Alternatively, was it intended to make an already expressible idea more convenient, more concise, more abstract, more concrete, more specific, more reliable, or more maintainable?

   (c) What shortcomings of existing languages prompted the discovery, invention, and/or introduction of this feature?

   (d) What set of expressive or methodological problems did this feature address at the time of its introduction? How was the absence of this feature handled prior to its introduction?

   • (d1) Does the feature address some specific application area?

   • (d2) Does the feature address a problem related to program organization?

   • (d3) Does the feature address a problem related to compile-time processing?

   • (d4) Does the feature address a problem related to run-time processing?

   • (d5) Does the feature address a problem related to a specific hardware architecture or class of architectures?

   • (d6) Does the feature address a problem related to operating systems, input/output, user interfaces, or networking?

   • (d7) Does the feature address a problem related to documentation?

   • (d8) Does the feature address a problem related to debugging?

   • (d9) Does the feature address a problem related to ensuring (or increasing the likelihood of) program correctness?

   • (d10) Does the feature make programs easier to write? To read? To compile? To execute? To verify?

   • (d11) To what extent did the feature support the coding of libraries (as opposed to end applications)?

   (e) How did this feature enhance a programmer’s ability to express the solution of a problem?

   (f) What forces (e.g., theoretical concerns, market demand, error-proneness of alternative forms) supported the introduction and evolution of the feature?

   (g) What external influences (e.g., changes in technology, new classes of problems, new classes of users) contributed to the need for this feature, or to its introduction and evolution?

   (h) What other features or concepts were precursors of this one? In which language(s) did they exist?

   (i) Was the feature intended to extend, supersede, provide an alternative to, or complement an already existing feature or concept?

   (j) Is the concept of a “negative” form that perhaps manifests itself as a lack of language features (e.g., there are no goto statements, there are no global variables, there are no side effects, multiple processes or threads cannot share data structures or pointers, the programmer cannot explicitly deallocate data structures)? What are the positive and negative consequences of such restrictions?

   • (j1) Did this concept require the creation of new complementary features, or the adoption of already existing features from other languages, to compensate for this lack?

   • (j2) Are such compensating features essentially the same in all languages that embody the concept, or did different languages end up with different sets of compensating feature? Why?

   (k) To what extent did implementation of the feature require changes to a compiler (e.g., intermediate code representations, code analyses, phase structure)? To the structure of compiler output (such “binary files”)? To linkers, loaders, debuggers, or other tools? To run-time organization (e.g., code, data, register conventions, stack organization, heap organization)? To libraries?

   (l) To what extent does the presence of the feature make interoperability another language easier or more difficult? Does the answer to this question depend on whether that other language does or does not also support or provide the feature?

3. Use and Subsequent Evolution

   (a) To what extent was the feature used in practice? Did its actual usage correspond to the expectations of its designers (in terms of both amount of use and nature of use)? Did experience from use lead to changes in the nature of the feature in the same language, or in subsequent languages?

   (b) How did this feature evolve over time? Into what other forms has the feature evolved in languages currently in use?

   (c) What language(s) have embodied or now embody this feature? (Please be as inclusive as you can. However, it may be appropriate to concentrate on a few exemplars when making comparisons.)

   • (c1) How does the feature manifest itself in each language? Give examples.

   • (c2) In what ways are these languages similar or different in their incorporation of the feature?

   • (c3) Why do languages differ in the ways they incorporate the feature? Do such differences cause any problems for users?

   (d) How did this feature interact with other features in the languages which embody it? How has this interaction influenced the evolution of this or other features? With what other language features is it most or least compatible? Are conflicts primarily syntactic or semantic in nature?

   (e) What obstacles (institutional, financial, psychological, political, temporal, technological, etc.) were encountered during the introduction and evolution of this feature? How did they affect it? How were they overcome?

   (f) What is the present incarnation of the feature, if any? In which languages can it be found today?

   (g) Were there competing or complementary features or concepts that conflicted with this one? If so, what was the nature of this conflict, and how was it resolved?

   (h) Has the feature itself evolved into distinct (and possibly competing) forms? Which languages exemplify these distinct forms? Why did differing forms arise?

   (i) Did the developers or users of the feature make any attempt to evaluate the feature objectively/empirically? Did the results lead to changes in the feature? Did such changes result in programs that were somehow better (e.g., shorter, more reliable, more efficient, easier to read, easier to maintain)?

4. A Posteriori Evaluation

   These questions are directed to assessing the feature or concept from today’s standpoint.

   (a) How well did the feature meet (or fail to meet) its expectations and goals?

   • (a1) Is the feature still available today in one or more widely used langages?

   • (a2) Is the feature still in widespread use today by programmers? If not, was the feature eventually superseded by yet another idea, or was it simply abandoned?

   • (a3) If the feature failed, why did it fail?

   (b) How did specific implementations affect its acceptance?

   (c) How was the feature received by those affected by it (e.g., programmers, problem solvers, documenters, managers)?

   (d) What were the biggest problems that arose during the design or creation of the feature? How were they addressed? Did these problems affect the end result significantly?

   (e) What were the biggest problems that arose during further evolution of the feature? How were they addressed?

   (f) If languages have differed in how they incorporate the feature, have such differences caused any problems for users? If so, have these problems been addressed? In what manner? Has addressing these problems resulted in further changes to the feature?

   (g) What are the biggest problems the users have had in understanding or using the feature? Does using the feature well require a significant amount of education, training, or experience?

   (h) What are the biggest problems the implementors have had? Were these deliberate, in the sense that a conscious decision was made to implement the feature “elegantly” or “completely”, even if it made the implementation more difficult?

   (i) Conversely, was a conscious decision made to implement the feature in “quick and dirty” manner or “incompletely”, in order to avoid certain implementation difficulties? Has this decision been made the same way in all languages that embody the feature, or have languages differed in how completely they implement the feature? Has the answer to this question changed over time?

   (j) What are the biggest problems the documenters of the feature have had? Would the language have been easier to document or to explain to users if the feature had been designed differently?

   (k) What other trade-offs were made during the feature design and implementation process? Were they conscious or unconscious?

   (l) What compromises were made to meet other constraints such as time, budget, user demands, political, or other factors?

   (m) If there are competing or complementary features or concepts that conflicted with this one:

   • (m1) Has the feature effectively displaced or even rendered obsolete some other feature?

   • (m2) Does the feature now coexist in the same language(s) with some competing or alternative feature? If so, in which situations may its use be considered preferable, and in which situations might an alternative be preferred?

   • (m3) Does the feature now exist in a language that competes with other languages that do not have the feature? If so, in which situations may the availability of the feature make use of its language preferable, and in which situations might an alternative language be preferred?

   (n) What other features or concepts were influenced by this one? Were other features or concepts later created specifically to complement, build on, or supersede this one?

   (o) How did this feature contribute to software methodology?

Questions for Authors: Class of Languages

The principal objective of a contribution in this category is to record the history of a class of languages. A class of languages is defined either by an application area for which they were intended (e.g., simulation, graphics, machine-tool control, scripting, interactive games) or by a language paradigm (e.g., functional, data-flow, object-oriented, constraint satisfaction, higher-order array operators).

The principal objective of a contribution in this category is to record the history of a class of languages. A class of languages is defined by a coherent set of unifying aspects or design criteria, such as:

• an intended application area (e.g., simulation, graphics, machine-tool control, scripting, interactive games, finance, database access, machine learning)

• a language paradigm (e.g., imperative, functional, data-flow, object-oriented, data parallel, logic programming, constraint satisfaction, higher-order array operators)

• distinctive characteristics (e.g., reflection, dynamic types, ownership types, two-dimensional notation, non-textual presentation and/or gestures, elaborate macro mechanisms, pattern matching, a specific approach to storage management, features that support verification of program correctness)

This question set has a quite different focus from the set dealing with the development of some particular language. Here the focus is on the distinctive characteristics of a set of languages; therefore much of the information solicited here is comparative. However, to the extent that you were party to the development of particular language(s) embodying this feature, it may be appropriate also to be guided by the Questions on the Early History of a [single] Language .

The Questions on the Evolution of a [single] Language should be consulted in any case.

A particular language paradigm or application area often implies particular programming language features, or particular restrictions or extensions of language features. Please consult the Questions on the History of a Language Feature or Concept for additional guidance.

1. Basic Information

   (a) What characterizes this class of languages (e.g., language paradigm or application area)?

   (b) Which languages are in this class? (Please be as comprehensive as possible, including early experimental languages.)

   (c) Did the class begin with a single language that then inspired all the others, or was there some degree of independent initial invention?

   (d) Who were the initial creator(s), what was their background, and how did they come to be involved in this class of languages?

   (e) When and by whom was this set of languages (or some initial subset) perceived as being a distinct class?

   (f) How (and why) did this class of languages grow and/or evolve after initial recognition as a class?

   (g) What are the basic publications (e.g., conference papers, technical reports, language manuals, books, websites) about this language class or particular languages within this class? Please make a special point of identifying as many of the early publications as possible, including informal or internal documents.

2. The Nature and Origin of This Class of Languages

   (a) What are the distinctive attributes of this class of languages? How did these attributes affect the features that the designers of these languages included or excluded?

   (b) What, if any, class of algorithms inspired the emergence of this language class? What application area(s) were these languages intended to address? How were these applications dealt with prior to the introduction of languages in this class?

   (c) What expectations and goals did the community interested in this class of languages have in mind?

   (d) What were the earliest languages in the class? How did they influence later languages in the class?

   (e) Describe the relevant characteristics of languages comprising the class. (Please discuss as many languages as you can. However, it may be appropriate to concentrate on a few exemplars.) In what ways are languages in the class similar? How do they differ? In particular, compare them with respect to:

   • (e1) declarative constructs (types, procedure and function headers)

   • (e2) imperative constructs (statements, assignments)

   • (e3) flow of control (conditionals, loops, procedure and function calls, nonlocal transfer of control)

   • (e4) program modularization constructs;

   • (e5) data encapsulation constructs

   • (e6) concurrency constructs

   • (e7) communication constructs

   • (e8) nesting of constructs, or prohibition of nesting

   • (e9) scope and extent of names

   • (e10) memory management (allocation, deallocation, reclamation)

   • (e11) processor management (thread creation, task assignment)

   • (e12) memory hierarchy and volatility

   • (e13) reflective capabilities

   • (e14) environmental interactions (time of day, inquiries about execution architecture)

   • (e15) input-output

   • (e16) interoperability with other languages in the class

   • (e17) interoperability with other languages outside the class

   • (e18) machine-dependent behaviors

   • (e19) undefined behaviors

   • (e20) other language-specific definitions, gestures, or behaviors?

   (f) Describe the ways in which the languages in the class similar or different with respect to meeting the goals of:

   • (f1) readability

   • (f2) writability

   • (f3) maintainability

   • (f4) reliability

   • (f5) portability

   • (f6) compile-time efficiency

   • (f7) run-time efficiency

   • (f8) testability

   • (f9) debuggability

   • (f10) teachability and explainability

   (g) Are there special editors or IDEs or other tools that accommodate many or all languages in the class? Alternatively, is the availability of a good editor or IDE or associated tool a feature that distinguishes certain members of the class from the others?

3. Evolution

   (a) How did this class of languages evolve over time? How did later languages in the class differ from earlier languages? What were the reasons for the differences? To what extent was upward compatibility a constraint? In what ways can the later languages be considered superior or inferior to the earlier ones? (A later language could, of course, be superior in some respects and inferior in others: it may be useful to treat the nature of these trade-offs. Consider Tony Hoare’s remark about Algol 60 in “Hints on Programming Language Design” (1973): “The more I ponder the principles of language design, and the techniques which put them into practice, the more is my amazement and admiration of ALGOL 60. Here is a language so far ahead of its time, that it was not only an improvement on its predecessors, but also on nearly all its successors.”)

   (b) To what extent did the languages in this class reflect external trends in programming language methodology (e.g., extension facilities, support for object-oriented programming, data abstraction, structured programming, pair programming, design patterns, agile programming)?

   (c) To what extent did the languages in this class reflect external trends or developments in computer hardware and operating systems (e.g., special-purpose hardware, availability of cheap processors and memory, multiprocessing, networking)?

   (d) Trace lines of influence among languages in the class, as well as comparative influence or lack of influence from languages outside the class. Describe the resulting “family tree” of both languages and development communities.

4. Evaluation

   (a) How well has this class of languages met (or failed to meet) its expectations and goals?

   (b) Has this class of languages proved to have applications beyond its original focus?

   (c) In the application area(s) relevant to the class, what are the competing languages (e.g., general purpose languages with special libraries) outside the class? How successful are the languages in the class versus these competing languages?

   (d) How did the languages in this class influence trends in programming language methodology?

   (e) How did this class of languages influence trends or developments in computer hardware and operating systems?

   (f) How has this class of languages influenced languages outside the class (e.g., by the latter incorporating characteristic features without adopting the underlying paradigm)?

   (g) Have ideas from this class of languages been adopted by more “general-purpose” languages?

   (h) Which early members of this language class have been superseded by later ones? Which continue to be used widely despite the emergence of later languages in the same class? Why?

REVISED AUTHOR RESOURCES FOR PREPARING FINAL COPY

Here are links to four files ( revised as of February 18, 2020 ) that authors will find helpful in preparing their final copy for HOPL IV.

(Alternatively, you can get all four files packaged as one zip file: RevisedAuthorResources.zip .)

1. The Revised HOPL IV Style Guide . Please read this Style Guide. It describes new ACM PACMPL recommendations for carefully distinguishing and documenting non-archival references, as well as new LaTeX and BibTeX facilities intended to make it easy to adopt these recommendations (though it is possible to satisfy the recommendations without using these new facilities, and this is explained also). The Style Guide also explains the finer points of correct citation style, as well as providing other recommendations about typography, grammar, and style; while these are not mandatory, they are intended to help you prepare a paper that is the best it can be: polished and easy to read.

   It is not necessary to read the entire Revised HOPL IV Style Guide if you have already read the earlier version.

   Here is a summary of the major changes to the Style Guide:

   • In response to feedback, the first six pages (about the citation model) have been rewritten. The model remains much the same, but the diagram has been adjusted and the use of terminology is now more consistent.

   • In response to feedback, we now recommend the use of {\sc non-archival} rather than {\sc na} in references to mark non-archival material. The \NA macro has been changed accordingly. (However, citations as produced by \citeNA still use {\sc na} .)

   • Some examples have been made longer, clearer, and/or more detailed.

   • If you have chosen to use ACM-HOPL-Reference-Format.bst , please re-read sections B3 and B4, which describe additional facilities for formatting URL-related fields that have been implemented in the last two weeks in response to feedback.

2. A required LaTeX style file acmshepherd.sty that defines the \shepherd command for mentioning the shepherd(s) of the paper. (Documentation for this feature is in a comment at the top of the file.)

   • The revised version corrects a small bug (a missing occurrence of \fi ).

   • The revised version corrects a bug in the LaTeX URL package that mishandles URLs that contains underscores.

   • The revised version defines the macro \NA to expand to {\sc non-archival} .

3. An optional LaTeX style file acmNArefs.sty that defines commands such as \citeNA to allow non-archival references to appear in a separate section of your bibliography. (Documentation for this feature is in Appendix B of the Style Guide.)

   • The revised version defines the macro \NA to expand to {\sc non-archival} for use in references (but citations still use {\sc na} ).

   • No other changes have been made to this file.

4. An optional BibTeX style file ACM-HOPL-Reference-Format.bst that supports additional fields useful for providing a précis and/or excerpt, additional URLs, and precise timestamps and date ranges. (Documentation for this feature is in Appendix B of the HOPL IV Style Guide.)

   • The revised version uses an abbreviated format in situations where the archivedurl is an URL for archive.org that contains a complete copy of the url field. (See Section B.2 of the Revised HOPL IV Style Guide .)

   • The revised version corrects a problem with using \url{...} within a non-URL field such as note .