ECOOP Technical Papers

ECOOP is a conference about programming. Originally its primary focus was on object orientation, but now it looks at a much broader range of programming topics. Areas of interest include the design, implementation, optimization, analysis, testing, verification, and theory of programs, programming languages, and programming environments. Papers may focus on new tools (e.g., language implementations, program analyses, runtime systems), techniques (e.g., code organization approaches, methodologies), principles (e.g., semantics, proofs, paradigms), evaluations (e.g., experiments, corpora analyses, user studies), or some combination of the above. ECOOP solicits both innovative and creative solutions to real problems as well as evaluations of existing solutions that provide new insights. It also encourages the submission of reproduction studies.

Supporters

Sponsor

Sponsor

Sponsor

Sponsor

Diamond

Platinum

Platinum

Gold

Gold

Gold

Silver

Accepted Papers

Call for Papers

ECOOP is a conference about programming. Originally its primary focus was on object orientation, but now it looks at a much broader range of programming topics. Areas of interest include the design, implementation, optimization, analysis, testing, verification, and theory of programs, programming languages, and programming environments. Papers may focus on new tools (e.g., language implementations, program analyses, runtime systems), techniques (e.g., code organization approaches, methodologies), principles (e.g., semantics, proofs, paradigms), evaluations (e.g., experiments, corpora analyses, user studies), or some combination of the above. ECOOP solicits both innovative and creative solutions to real problems as well as evaluations of existing solutions that provide new insights. It also encourages the submission of reproduction studies.

ECOOP 2021 solicits high-quality submissions describing original, unpublished results. The program committee will evaluate the technical contribution of each submission as well as its general relevance and accessibility to the ECOOP audience according to the following criteria:

• Originality. Papers must present new ideas and place them appropriately within the context established by previous research in the field.

• Significance. The results in the paper must have the potential to add significantly to the state of the art or practice.

• Evidence. The paper must present evidence supporting its claims. Examples of evidence include implemented systems, experimental results, statistical analyses, case studies, formalizations, and proofs.

• Clarity. The paper must present its contributions and results clearly.

On submission, authors will be asked to identify their paper with one of the following categories:

• Research Paper. This is the most traditional category and solicits high quality research papers that demonstrate advances in the field. (As an alternative to being published in the conference proceedings, authors may wish to submit research papers to be considered for publication in ACM TOPLAS or Science of Computer Programming; see below.)

• Tool Insights Paper. These submissions focus on the practical details of the design and implementation of PL tools—details that are often omitted from regular research papers, despite being fascinating and worthy of communication. A strong Tool Insights Paper should communicate engineering experience and insights that are likely to be useful to other members of the PL community, who may face similar problems in future. Examples of issues that Tool Insights Papers might focus on include, but are not limited to: performance, reliability, portability, inter-tool integration, infrastructure re-use, evaluation issues, theory/practice gaps, precision/efficiency, and soundness/efficiency trade-offs.

• Reproduction Study. A Reproduction Study is an empirical evaluation. It reconstructs an already published experiment but in a different context (for example, using a different virtual machine or platform, or in a different class of applications) in order to validate or refute important results of earlier work. A good Reproduction Study includes thorough empirical evaluation as well as a detailed comparison with the previous results, providing reasons for possible disagreements. (A thoroughly-conducted Reproduction Study that perfectly replicates an existing experiment and reaches the same conclusions will be regarded as significant, so long as said experiment is significant enough to be worthy of reproduction.)

• Experience Report. Such reports focus on noteworthy applications of known PL techniques, tools, and ideas in interesting domains and by other communities. Examples include, but are not limited to, applications of PL techniques in industry, open source, education, and other academic disciplines. We welcome reports on successful applications of PL ideas and reports that shed light on limitations and problems that may provide inspiration for future research.

• Pearl. This category solicits articles that explain a known idea in a new and elegant way, to the benefit of the PL community. A Pearl may well be shorter than a regular research paper, but there is no hard requirement on this.

• Brave New Idea. The Brave New Idea category solicits forward-looking articles on ideas in the field of PL that may take some time to substantiate, but for which early communication to the community is likely to be of benefit. For this category we welcome papers that are particularly conceptually novel or unconventional and that as a result may be harder to back up by traditional evaluation methods. A Brave New Idea paper may well be shorter than a regular research paper, but there is no requirement for it to be so.

Paper Submission

Only papers that have not been published and are not under review for publication elsewhere may be submitted. Double submissions will be rejected without review. If major parts of an ECOOP submission have appeared elsewhere in any form, authors are required to notify the ECOOP program chair and explain the overlap and relationship. Authors are also required to inform the program chair about closely related work submitted to another conference while the ECOOP submission is under review.

Papers must be no longer than 25 pages, excluding references. See below for information about appendices. Authors will not be penalized for papers that are shorter than the page limit.

Submissions will be carried out electronically via HotCRP.

ECOOP Proceedings are published by Dagstuhl LIPIcs. Papers must be written in English and follow the Dagstuhl LIPIcs LaTeX-style template. Authors retain ownership of their content.

Note: Submitted papers do not need to include the ACM classification or keywords. Also, please DO NOT put your name in either the \author or \Copyright macro, in order to maintain anonymity for double-blind reviewing (see below).

Anonymity

ECOOP will use double-blind reviewing, where authors’ identities are only revealed if a paper is accepted (a.k.a. strong double-blind reviewing). To facilitate this, papers must adhere to three rules:

1. author names and institutions must be omitted, and
2. references to authors’ own related work should be in the third person (e.g., not “We build on our previous work …” but rather “We build on the work of …”), and
3. any supplementary material should be similarly anonymized.

The purpose of this process is to help reviewers decide whether to accept a submission without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult.

For further details, see the double-blind reviewing FAQ. If there are any doubts, please contact the program chair.

Additional Material

Clearly marked additional appendices containing analyses, statistics, supporting proofs, etc. of possible value to reviewers but not published in the final publication, may be included beyond the page limit. The submission system provides an option to submit supplementary material; for example, a technical report including proofs, or an archive of code or raw data. All supplementary material must be anonymized to facilitate double-blind review.

Reviewers are under no obligation to examine such appendices and supplementary material. Therefore, the paper must be a stand-alone document - the appendices and supplementary material are a way of providing useful information that cannot fit in the page limit; they are not a means to extend the page limit.

Response Period

Authors will be given a six-day period (four weekdays) to read and respond to the reviews of their papers before the program committee meeting. Responses have no formal length limit, but concision is likely to be effective.

Artifact Evaluation and Intent

To reward the creation of artifacts and support replication of experiments, authors of accepted research papers may submit artifacts (such as tools, data, models, or videos) to be evaluated by an Artifact Evaluation Committee. Artifacts that pass muster will be recognized officially.

To further encourage submission of artifacts, authors will be asked whether they intend to submit an artifact for evaluation during the paper submission process, and to provide an explanation if they do not intend to do so. (Note that artifact submission may not be appropriate for all papers (e.g., a Brave New Idea paper), and it is perfectly acceptable to not submit an artifact in such cases.) Information on artifact intent for a submission will be shared with reviewers. Skipping artifact submission without appropriate justification after indicating intent to submit may be grounds for paper rejection.

Important Dates

• Paper submission: 11 January 2021 (Mon)

• Author response: 10–15 March 2021 (Wed–Mon)

• Author notification: 1 April 2021 (Thu)

Journal First

We have Journal First arrangements with ACM Transactions on Programming Languages and Systems and Elsevier Science of Computer Programming.

Common to both routes

Only new research papers are eligible for the Journal First routes to ECOOP 2021. That is, it is not acceptable to submit an extension of a previous conference paper, even if the associated journal solicits extended papers via its standard submission route.

Authors of all accepted Journal First papers will be invited to submit a short abstract for their paper to appear in the ECOOP 2021 conference proceedings.

Journal First papers will be included along with research papers submitted directly to the conference when a Distinguished Paper is selected.

ACM Transactions on Programming Languages and Systems route

See this announcement for details of the TOPLAS scheme whereby papers submitted to TOPLAS can be presented at selected conferences.

Authors interested in this route should submit their paper to TOPLAS via its usual submission system and mark it as an ECOOP 2021 submission. The ECOOP Program Chair will then be informed of this submission and will have some input into the review process.

Submission deadline: October 13, 2020

Science of Computer Programming route

See the call for papers for the Science of Computer Programming ECOOP 2021 Special Issue for full details.

Submission deadline: November 2, 2020

More Information

For additional information, please contact the ECOOP Program Chair, Manu Sridharan.

The following content is based heavily on the PLDI’20 DBR FAQ.

General

Q: Why double-blind reviewing?

A: Studies have shown that a reviewer’s attitude toward a submission may be affected, even unconsciously, by the identity of the authors. We want reviewers to be able to approach each submission without any such, possibly involuntary, pre-judgment. Many computer science conferences have embraced double-blind reviewing.

Q: Do you really think blinding actually works? I suspect reviewers can often guess who the authors are anyway.

A: It is rare for authorship to be guessed correctly, even by expert reviewers, as detailed in this study.

Q: Couldn’t blind submission create an injustice where a paper is inappropriately rejected based upon supposedly-prior work which was actually by the same authors and not previously published?

A: Reviewers are held accountable for their positions and are required to identify any supposed prior work that they believe undermines the novelty of the paper. Any assertion that “this has been done before” by reviewers should be supported with concrete information. The author response mechanism exists in part to hold reviewers accountable for claims that may be incorrect.

For Authors

Q: What exactly do I have to do to anonymize my paper?

A: Use common sense. Your job is not to make your identity undiscoverable but simply to make it possible for reviewers to evaluate your submission without having to know who you are. The specific guidelines stated in the call for papers are simple: omit authors’ names from your title page, and when you cite your own work, refer to it in the third person. For example, if your name is Smith and you have worked on amphibious type systems, instead of saying “We extend our earlier work on statically typed toads [Smith 2004],” you might say “We extend Smith’s [2004] earlier work on statically typed toads.” Also, be sure not to include any acknowledgements that would give away your identity. In general, you should aim to reduce the risk of accidental unblinding. For example, if your paper is the first to describe a system with a well-known name or codename, or you use a personally-identifiable naming convention for your work, then use a different name for your submission (which you may indicate has been changed for the purposes of double-blind reviewing). You should also avoid revealing the institutional affiliation of authors or at which the work was performed.

Q: How do I provide supplementary material?

A (and also see the next question): On the submission site there will be an option to submit supplementary material along with your main paper. This supplementary material should also be anonymized—it may be viewed by reviewers during the review period, so it should adhere to the same double-blind guidelines.

Q: My submission is based on code available in a public repository. How do I deal with this?

A: Making your code publicly available is not incompatible with double-blind reviewing. You should do the following. First, cite the code in your paper, but remove the actual URL and, instead say “link to repository removed for double blind review” or similar. Second, if, when writing your author response, you believe reviewer access to your code would help, say so in your author response (without providing the URL), and send the URL to the Program Chair.

Q: I am building on my own past work on the WizWoz system. Do I need to rename this system in my paper for purposes of anonymity, so as to remove the implied connection between my authorship of past work on this system and my present submission?

A: Maybe. The core question is really whether the system is one that, once identified, automatically identifies the author(s) and/or the institution. If the system is widely available, and especially if it has a substantial body of contributors and has been out for a while, then these conditions may not hold (e.g., LLVM or HotSpot), because there would be considerable doubt about authorship. By contrast, a paper on a modification to a proprietary system (e.g., Visual C++, or a research project that has not open-sourced its code) implicitly reveals the identity of the authors or their institution. If naming your system essentially reveals your identity (or institution), then anonymize it. In your submission, point out that the system name has been anonymized. If you have any doubts, please contact the Program Chair.

Q: I am submitting a paper that extends my own work that previously appeared at a workshop. Should I anonymize any reference to that prior work?

A: No. But we recommend you do not use the same title for your ECOOP submission, so that it is clearly distinguished from the prior paper. In general, there is rarely a good reason to anonymize a citation. One possibility is for work that is tightly related to the present submission and is also under review. When in doubt, contact the Program Chair.

Q: Am I allowed to post my (non-blinded) paper on my web page? Can I advertise the unblinded version of my paper on mailing lists or send it to colleagues? Can I give a talk about my work while it is under review? How do I handle social media? What about arXiv?

A: We have developed guidelines, described here, to help everyone navigate in the same way the tension between the normal communication of scientific results, which double-blind reviewing should not impede, and actions that essentially force potential reviewers to learn the identity of the authors for a submission. Roughly speaking, you may (of course!) discuss work under submission, but you should not broadly advertise your work through media that is likely to reach your reviewers. We acknowledge there are gray areas and trade-offs; we cannot describe every possible scenario.

Things you may do:

• Put your submission on your home page.
• Discuss your work with anyone who is not on the review committees, or with people on the committees with whom you already have a conflict.
• Present your work at professional meetings, job interviews, etc.
• Submit work previously discussed at an informal workshop, previously posted on arXiv or a similar site, previously submitted to a conference not using double-blind reviewing, etc.

Things you should not do:

• Contact members of the review committees about your work, or deliberately present your work where you expect them to be.
• Publicize your work on major mailing lists used by the community (because potential reviewers likely read these lists).
• Publicize your work on social media if wide public [re-]propagation is common (e.g., Twitter) and therefore likely to reach potential reviewers. For example, on Facebook, a post with a broad privacy setting (public or all friends) saying, “Whew, ECOOP paper in, time to sleep” is okay, but one describing the work or giving its title is not appropriate. Alternately, a post to a group including only the colleagues at your institution is fine.

Reviewers will not be asked to recuse themselves from reviewing your paper unless they feel you have gone out of your way to advertise your authorship information to them. If you are unsure about what constitutes “going out of your way”, please contact the Program Chair.

Q: Will the fact that ECOOP is double-blind have an impact on handling conflicts-of interest?

A: Double-blind reviewing does not change the principle that reviewers should not review papers with which they have a conflict of interest, even if they do not immediately know who the authors are. Authors declare conflicts-of-interest when submitting their papers using the guidelines in the call-for-papers. Papers will not be assigned to reviewers who have a conflict.

For Reviewers

Q: What should I do if I if I learn the authors’ identity?

A: If at any point you feel that the authors’ actions are largely aimed at ensuring that potential reviewers know their identity, you should contact the Program Chair. Otherwise you should not treat double-blind reviewing differently from regular blind reviewing. In particular, you should refrain from seeking out information on the authors’ identity, but if you discover it accidentally this will not automatically disqualify you as a reviewer. Use your best judgment.

Q: The authors provided a URL to supplemental material, I worry they will snoop my IP address. What should I do?

A: Contact the Program Chair, who will download the material on your behalf and make it available to you.

Q: Can I seek an outside review?

A: No. PC members should do their own reviews. If doing so is problematic, e.g., you don’t feel qualified, then consider the following options. First, submit a review that is as careful as possible, outlining areas where you think your knowledge is lacking. Assuming we have sufficient expert reviews, that could be the end of it: non-expert reviews are valuable too. Second, the review form provides a mechanism for suggesting additional expert reviewers to the PC Chair, who may contact them if additional expertise is needed. Please do not contact outside reviewers yourself. As a last resort, if you feel like your review would be extremely uninformed and you’d rather not even submit a first cut, contact the Program Chair.