The PEPM Symposium/Workshop series aims at bringing together researchers and practitioners working in the areas of program manipulation, partial evaluation, and program generation. PEPM focuses on techniques, theory, tools, and applications of analysis and manipulation of programs.

PEPM 2016 will feature a series of high-caliber invited talks that cover the core of PEPM - program manipulation - from different angles. Most of the invited talks will take place on Monday, Jan 18.

Accepted Papers

Please see the list of accepted papers here

Invited Talks

PEPM 2016 will feature a series of high-caliber invited talks that cover the core of PEPM - program manipulation - from different angles. Most of the invited talks will take place on Monday, Jan 18. Please see the full list here

Accepted Papers

Call for Papers

The 2016 PEPM workshop will be based on a broad interpretation of semantics-based program manipulation and continues efforts to expand the scope of PEPM beyond the traditionally covered areas of partial evaluation and specialization. Specifically, PEPM will include practical applications of program transformations such as refactoring tools, and practical implementation techniques such as rule-based transformation systems. In addition, the scope of PEPM covers manipulation and transformations of program and system representations such as structural and semantic models that occur in the context of model-driven development. In order to reach out to practitioners, a separate category of tool demonstration papers will be solicited.

Topics of interest for PEPM’16 include, but are not limited to:

• Program and model manipulation techniques such as: supercompilation, partial evaluation, fusion, on-the-fly program adaptation, active libraries, program inversion, slicing, symbolic execution, refactoring, decompilation, and obfuscation.

• Program analysis techniques that are used to drive program/model manipulation such as: abstract interpretation, termination checking, binding-time analysis, constraint solving, type systems, automated testing and test case generation.

• Techniques that treat programs/models as data objects including metaprogramming, generative programming, embedded domain-specific languages, program synthesis by sketching and inductive programming, staged computation, and model-driven program generation and transformation.

• Application of the above techniques including case studies of program manipulation in real-world (industrial, open-source) projects and software development processes, descriptions of robust tools capable of effectively handling realistic applications, benchmarking. Examples of application domains include legacy program understanding and transformation, DSL implementations, visual languages and end-user programming, scientific computing, middleware frameworks and infrastructure needed for distributed and web-based applications, resource-limited computation, and security.

To maintain the dynamic and interactive nature of PEPM, we will continue the category of `short papers’ for tool demonstrations and for presentations of exciting if not fully polished research, and of interesting academic, industrial and open-source applications that are new or unfamiliar.

Student participants with accepted papers can apply for a SIGPLAN PAC grant to help cover travel expenses and other support. PAC also offers other support, such as for child-care expenses during the meeting or for travel costs for companions of SIGPLAN members with physical disabilities, as well as for travel from locations outside of North America and Europe. For details on the PAC program, see its web page.

All accepted papers, short papers included, will appear in formal proceedings published by ACM Press. Accepted papers will be included in the ACM Digital Library. Selected papers from PEPM’16 will be published in a special issue of the journal Science of Computer Programming.

PEPM has also established a Best Paper Award. The winner will be announced at the workshop.

Submission Categories and Guidelines

Authors are encouraged to consult the advice for authoring research papers and tool papers before submitting. Regular Research Papers must not exceed 12 pages in ACM Proceedings style (including appendix). Tool demonstration papers and short papers must not exceed 6 pages in ACM Proceedings style (including appendix). At least one author of each accepted contribution must attend the workshop and present the work. In the case of tool demonstration papers, a live demonstration of the described tool is expected. Suggested topics, evaluation criteria, and writing guidelines for both research tool demonstration papers will be made available on the PEPM’16 web site.

Papers should be submitted electronically via EasyChair.

Authors using LaTeX to prepare their submissions should use the new improved SIGPLAN proceedings style. Specifically, use the sigplanconf.cls 9pt template.

Important Dates

• Abstract submission: Tuesday, September 8, 2015
• Paper submission: Sunday, September 13, 2015 (FIRM)
• Author notification: Tuesday, October 13, 2015
• Camera ready copies due: Wednesday, November 25, 2015
• Workshop: Monday, January 18 - Tuesday, January 19, 2016

Note: The paper submission deadline is firm. The above schedule is tight: We have absolutely no time to wait for late submissions and we will have no deadline extension. Please take this into account, and plan ahead accordingly.

Electronic Submission

Papers must be submitted electronically in PDF format at:

https://easychair.org/conferences/?conf=pepm2016

The PEPM Symposium/Workshop series aims to bring together researchers and practitioners working in the broad area of program transformation and generation. We hope that PEPM authors will find the following advice helpful in preparing their submissions. Tool demonstration papers have special requirements, described in Tool Paper Advice.

Program Goals

The topics covered by PEPM are listed in the Call for Papers. Please contact one of the program chairs if you have further questions about PEPM’s scope.

Original Work

All papers should be original work, and not have been previously published nor have been submitted to, or be in consideration for, any journal, book, conference, or workshop. The novelty requirement is relaxed for Tool Demonstration Papers.

Commendable Qualities

• Clear contributions: The contributions of the paper should be stated explicitly in the introduction of the paper and elaborated in the rest of it. Limitations should be acknowledged; if possible, future work should mention the ways to overcome these limitations.

• Well-written: In particular, the authors should strive to make the paper free from spelling and grammatical mistakes.

• Good examples: Every major point should be illustrated with an example.

• Well-supported claims: Any claims of performance improvements, ease of use, scalability, etc. must be justified by the appropriate evidence, such as computational cost analyses, benchmarks, usability studies, multiple case studies and so on.

• *Relevant to real-world problems: Authors should clearly indicate actual real-world scenarios in which they envision their work (when fully mature) being applied. Issues such as scalability, analysis precision, degree of automation, learning curve, etc. that might hinder the use of the technique in practice should be acknowledged and assessed.

• Properly positioned to related work: Submissions should include a related work section that summarizes and contrasts with closely related work. Related work should not simply list previous papers with a brief summary of their contents, nor should it state only the strengths of the submission and the weakness of previous work. A proper related work section should state both the strengths and weaknesses of the submission and indicate situations in which one method might be preferred over another.

• Clear methodology and integration into larger development context: Authors should clearly indicate the steps that users should go through to apply a technique including any manual preprocessing, tool configuration, assessment of output, etc. Moreover, an assessment of how the technique fits into the context of other development tools such as debuggers, test frameworks, integrated development environments, etc. For example, if the proposed technique is a generative programming technique in which users are not expected to read generated code, what mechanisms might be provided to aid debugging of generated code. In another case, how does the transformation interact with the use of library code? Is there any impact on how the system is tested?

• Supporting material: If at all possible, the authors are encouraged to make examples, data, tools or other artifacts presented in the paper freely available online.

Common Flaws

• Lack of simple examples: Every major point in the paper should be illustrated with an example. When introducing a new technique or analysis, it is wholly appropriate to use simple, well-known examples such as the “power function” and the “dot product”.

• Lack of realistic examples: The paper will hopefully claim that its technique and analyses scale to real-world problems. These claims should also be illustrated with an appropriate large example. If the example is too large to fully describe in the paper, the paper should give the highlights and refer to the complete explanation online: a web page, a technical report, or well-commented source code.

• Lack of clear correctness notions: the authors should explicitly state what it means for their technique or analysis to be correct. For example, a paper on program transformation must state what properties of programs are preserved by the transformation. The authors should argue, perhaps informally, how their implementation or tool meets or approximates the correctness properties, or give a clear statement of the pre-conditions for the successful application of the technique. Detailed proofs need not be included in the submission but may be referred to in a URL or a technical report.

• Lack of clear methodology: Many papers present techniques without telling what the users have to do, step-by-step, to apply the techniques. Issues such as initial binding-time improvement or refactoring of source code, stubbing out or annotating library methods, etc. are often ignored. As a classic example, many early PEPM papers “swept under the rug” the need for manual binding-time improvements and annotations. As the result, non-experts have had significant trouble applying partial evaluation techniques in practice.

• Poor related work comparisons: Papers often suffer from poor related work comparisons in which authors follow a pattern “our tool is better at TASK-X than tool T1 because …, our tool is better at TASK-Y than tool T2 because …” (all the while ignoring the fact that tool T1 has a much broader scope than the authors’ tool or that it is in fact better than the authors’ tool for many aspects not mentioned in the paper). Authors should strive to give a balanced and fair assessment listing both strengths and weakness of all work considered.

Example Paper Types

• New transformation technique: The most common type of PEPM paper will report on a new analysis/transformation technique. Such papers should include a detailed description of the technique, some sort of formal or informal argument about why the technique is correct, illustrate the technique on interesting examples, and evaluate the effectiveness of the technique.

• Case studies: This type of paper reports on a large-scale application of an existing technique. Such papers should clearly state the insights and the lessons of the study. Was the technique effective? Was it easy to apply? What pitfalls were overcome and what difficulties remain? One must clearly distinguish anecdotal performance claims from rigorously established ones.

• Description of new/interesting domain and potential for effective use of PEPM techniques: This type of paper describes a particular application domain (e.g., middleware, avionics systems, active networks) or a particular development paradigm (e.g., model-driven development) detailing how techniques within the scope of PEPM might be applied effectively in that domain. Special attention should be given to enumerating the problems/challenges of the domain, characteristics that suggest that it might benefit from PEPM techniques, initial attempts at applying those techniques, and questions/challenges to be addressed by future work. Such papers should aim to educate the PEPM community about interesting/fundamental issues of the domain, and give pointers to where they may learn more about the issues.

Short papers

We do encourage submissions of “work in progress” in cases where the submission raises issues that will generate interesting discussions at the meeting, brings new knowledge of a particular application domain or technique to the community, or lays out challenging open problems of high relevance to software engineering practice. Depending on the quality and number of such submissions, we may collect work-in-progress papers into a single session with slightly shorter time slots for each presentation and a longer discussion time at the end of the session.

PEPM has a special category of papers called tool demo papers. The main purpose of a tool paper is to display other researchers in the PEPM community a completed, robust and well-documented tool – highlighting the overall functionality of the tool, the interfaces of the tool, interesting examples and applications of the tool, an assessment of the tool’s strengths and weaknesses, and a summary of documentation/support available with the tool.

Tool demo paper submissions must satisfy the following requirements.

• The body of the paper must be no longer than 6 pages in length using the two-column ACM Conference style. The body of the paper should give an overview of the tool, the methodology associated with its use, a summary of how the tool has been applied and to what effect, and it should indicate what supporting artifacts (user manual, example repository, downloads, etc.) are available, together with a URL to a web-site giving documentation and further information about the tool. This material will be included in the PEPM proceedings for accepted tool demos. Because tool papers have a different format and a different purpose than regular research papers, we would like to (a) describe in more detail the characteristics of a good tool paper, and (b) give the explicit evaluation criteria that will be used by the PEPM program committee when selecting tool papers.

Regular research papers may also describe the details of a particular tool, but note that there are important differences between the contents of a tool demo paper and a research paper that describes a tool. Research papers about tools clearly describe how aspects of the tool (e.g., its architecture, underlying algorithms, combinations of techniques, functionality, etc.) advance the state of the art. This should include a detailed comparison with related work. Moreover, research papers about tools should usually include the results/data of experimental studies that rigorously demonstrate the effectiveness of the claimed scientific advance. On the other hand, the main purpose of a tool demo paper is not to rigorously justify the scientific advances of the tool (although the tool demo paper may contain a concise list of advances or references to other research papers). Rather, a tool demo paper should simply provide concise summary of the current state of a tool and describe how researchers in the PEPM community might apply it effectively.

Below we list the explicit evaluation criteria that will be used by the PEPM committee when selecting tool papers.

• Technical Foundations: In keeping with the overall goals of PEPM, described tools should be based on well-reasoned semantic principles. Even though the shorter length of tool papers will not allow authors to provide significant technical details of the theory underlying the tool, submissions should give a concise summary of the technical foundations and provide references to related work where more technical details are presented.

• Novelty: In contrast with regular PEPM submissions, PEPM tool demo papers may include work that has been published elsewhere. In the ideal case, the technical foundations of the tool will have been published previously, and the submitted PEPM tool paper will report on follow-on work that has produced a robust tool that has been applied to interesting examples. The PEPM program committee will consider accepting tool demo papers that describe tools that have been presented at other conferences/workshops if these conferences/workshops belong to a different community. For example, if a tool has been demonstrated at an operating system conference, the PEPM program committee might also consider accepting the same tool to be shown at PEPM if it is determined that the demo could provide interesting and new insights to the PEPM community. If tool demo papers are submitted for tools that have presented elsewhere, authors should include a statement in the paper that acknowledges previous demos and that justifies the benefits of presenting the tool again for the PEPM audience. In summary, the “novelty” expected of a tool demo paper is not “never been published before or presented elsewhere”, but instead “new useful and practical information provided to the PEPM community”.

• Stability: PEPM tool demo papers should describe tools with reasonably complete implementations. Tools where significant components are not fully implemented or tested and tools which have not been applied to interesting examples will not be considered. It is expected that tool demos will describe well-engineered internal architectures and interfaces.

• Robustness: Tool demo papers will also be evaluated for evidence of tool robustness. This might include evidence that the tool has been applied to a variety of examples, or used by others outside of the research group that developed the tools. Documentation: The tools should be presented on a web-site that includes documentation for installation and a user manual that describes the basic use of the tool, its options, and its application to at least on example.

• Example Repository: Ideally, tools should include a repository of examples (e.g., contained in the tool distribution or available on the tool web site) along with a description of how to run the tool on the examples.

• Public Availability: Preference will be given to tools that are freely available (e.g., downloadable from the tool web site) so that other researchers in the PEPM community can independently evaluate the tool. Exceptions may be made for tools from industry and commercial tools that cannot be made publicly available for business reasons. Interesting Public Presentation: Evaluation of tool demo papers will include an assessment of the potential quality of the tool demo (e.g., completeness of tool implementation, depth of functionality, quality of user interfaces, application and assessment of interesting examples) as presented in the attached appendix described above that outlines the demo session.

Authors with further questions about the structure, contents, or suitability of a potential tool demo paper should contact the program chairs.