Empathy List Archives

esug-list@lists.esug.org

Language Workbench Challenge 2016: Call for Solutions

Tijs van der Storm

Wed, Jun 1, 2016 12:55 PM

#############################################################
Language Workbench Challenge 2016 @ SLE: Call for Solutions
Collocated with SPLASH'16 in Amsterdam, The Netherlands

Deadline: Mon 1 Aug 2016
Notification: Mon 5 Sep 2016
Workshop: Tue 1 Nov 2016

http://2016.splashcon.org/track/lwc2016
#############################################################

Language workbenches are tools that lower the development costs of
implementing new languages and their associated tools (IDEs, debuggers
etc.). As well as easing the development of traditional stand-alone
languages, language workbenches also make multi-paradigm and
language-oriented programming environments practical. The Language
Workbench Challenge (LWC) aims to bring together language workbench users
and implementers, to discuss the state-of-the-art in language workbenches
and explore future directions.

LWC’16 solicits solutions to 3 benchmark problems proposed in Section 6.5
of the following paper:

Sebastian Erdweg, Tijs van der Storm, Markus Völter, Laurence Tratt, et

al.
Evaluating and comparing language workbenches: Existing results and
benchmarks for the future,
Computer Languages, Systems & Structures, Volume 44, Part A, December
2015, Pages 24–47.

DOI: http://dx.doi.org/10.1016/j.cl.2015.08.007
Preprint: http://homepages.cwi.nl/~storm/publications/lwc13-comlan.pdf

The benchmark problems are categorized in the following categories:

Notation: challenges dealing with the appearance of source code,
including support for tabular notation, mathematical symbols, code in prose
etc.
Evolution and reuse: challenges related to modularity, composition,
language versions and migration.
Editing: challenges exercising how the language user interacts with code.

The goal of the workshop is to demonstrate, discuss and foster improvements
in tools, as well as encourage the collaboration between and learning among
different teams developing different (kinds of) editors. To this end, we
emphasize the implementation of the challenges, not writing about them.
Submissions should be short documents (in PDF format) describing each
solution using the following structure:

Assumptions: Are there any assumptions or prerequisites relevant to the
implementation of the solution?
Implementation: What are the important building blocks for defining the
solution? What does it take to implement the solution to the problem?
Variants: Are there any interesting and insightful variants of the
implementation? What small change(s) to the challenge would make a big
difference in the implementation strategy or effort?
Usability: What is the resulting user experience? Is it convenient to
use? Is it similar to other kinds of notations? Does it feel ’foreign’ to
experienced users of the particular editor?
Impact: Which artifacts have to be changed to make the solution work? Are
changes required to (conceptually) unrelated artifacts? How modular is the
solution?
Composability: To what degree does the solution support composition with
solutions to other benchmark problems other instances of the same problem
(e.g., same challenge problem, different language feature)?
Limitations: What are the limitations of this implementation?
Uses and Examples: Are there examples of this problem in real-world
systems? Where can the reader learn more?
Effort (best-effort): How much effort has been spent to build the
solution, assuming an experienced user of the technology?
Other Comments: Anything that does not fit within the other categories.
Artifact: a publicly accessible URL to the source code of the submission.

The paper cited above includes two example descriptions for inspiration,
Submissions should furthermore use the ACM SIGPLAN Conference Format, 10
point font, using the font family Times New Roman and numeric citation
style.

The PC will review the submissions for inclusion in the workshop program,
based on criteria of providing interest for discussion, conformance to the
challenges, and whether the submission is on-topic (e.g., is using a
language workbench). The PDFs of accepted submissions will be published on
this website before the workshop.

Organization

Meinte Boersma (Mendix)
Eugen Schindler (Oce)
Tijs van der Storm (CWI)
Markus Voelter (itemis AG)

Program Committee

Lorenzo Bettini (DISIA)
Sebastian Erdweg (TU Delft)
Pablo Inostroza (CWI)
Tamás Szabó (itemis AG / TU Darmstadt)

############################################################# Language Workbench Challenge 2016 @ SLE: Call for Solutions Collocated with SPLASH'16 in Amsterdam, The Netherlands Deadline: Mon 1 Aug 2016 Notification: Mon 5 Sep 2016 Workshop: Tue 1 Nov 2016 http://2016.splashcon.org/track/lwc2016 ############################################################# Language workbenches are tools that lower the development costs of implementing new languages and their associated tools (IDEs, debuggers etc.). As well as easing the development of traditional stand-alone languages, language workbenches also make multi-paradigm and language-oriented programming environments practical. The Language Workbench Challenge (LWC) aims to bring together language workbench users and implementers, to discuss the state-of-the-art in language workbenches and explore future directions. LWC’16 solicits solutions to 3 benchmark problems proposed in Section 6.5 of the following paper: Sebastian Erdweg, Tijs van der Storm, Markus Völter, Laurence Tratt, et al. **Evaluating and comparing language workbenches: Existing results and benchmarks for the future**, Computer Languages, Systems & Structures, Volume 44, Part A, December 2015, Pages 24–47. DOI: http://dx.doi.org/10.1016/j.cl.2015.08.007 Preprint: http://homepages.cwi.nl/~storm/publications/lwc13-comlan.pdf The benchmark problems are categorized in the following categories: - Notation: challenges dealing with the appearance of source code, including support for tabular notation, mathematical symbols, code in prose etc. - Evolution and reuse: challenges related to modularity, composition, language versions and migration. - Editing: challenges exercising how the language user interacts with code. The goal of the workshop is to demonstrate, discuss and foster improvements in tools, as well as encourage the collaboration between and learning among different teams developing different (kinds of) editors. To this end, we emphasize the implementation of the challenges, not writing about them. Submissions should be short documents (in PDF format) describing each solution using the following structure: - Assumptions: Are there any assumptions or prerequisites relevant to the implementation of the solution? - Implementation: What are the important building blocks for defining the solution? What does it take to implement the solution to the problem? - Variants: Are there any interesting and insightful variants of the implementation? What small change(s) to the challenge would make a big difference in the implementation strategy or effort? - Usability: What is the resulting user experience? Is it convenient to use? Is it similar to other kinds of notations? Does it feel ’foreign’ to experienced users of the particular editor? - Impact: Which artifacts have to be changed to make the solution work? Are changes required to (conceptually) unrelated artifacts? How modular is the solution? - Composability: To what degree does the solution support composition with solutions to other benchmark problems other instances of the same problem (e.g., same challenge problem, different language feature)? - Limitations: What are the limitations of this implementation? - Uses and Examples: Are there examples of this problem in real-world systems? Where can the reader learn more? - Effort (best-effort): How much effort has been spent to build the solution, assuming an experienced user of the technology? - Other Comments: Anything that does not fit within the other categories. - Artifact: a publicly accessible URL to the source code of the submission. The paper cited above includes two example descriptions for inspiration, Submissions should furthermore use the ACM SIGPLAN Conference Format, 10 point font, using the font family Times New Roman and numeric citation style. The PC will review the submissions for inclusion in the workshop program, based on criteria of providing interest for discussion, conformance to the challenges, and whether the submission is on-topic (e.g., is using a language workbench). The PDFs of accepted submissions will be published on this website before the workshop. Organization - Meinte Boersma (Mendix) - Eugen Schindler (Oce) - Tijs van der Storm (CWI) - Markus Voelter (itemis AG) Program Committee - Lorenzo Bettini (DISIA) - Sebastian Erdweg (TU Delft) - Pablo Inostroza (CWI) - Tamás Szabó (itemis AG / TU Darmstadt)