1.2Overview

SNAPL focuses on experience-based insight, innovation, and visionary
ideas spanning from foundations to applications of programming
languages. We welcome perspectives from both industry and academia.

SNAPL defines itself in opposition to conventional conferences. Papers
with traditional results that could have been published at a
conventional conference or workshop will automatically be rejected, no
matter how good the result. In contrast, papers that would not easily
find a home at conventional venues are very welcome here. These might
include:

visionary ideas requiring years of exploration and evaluation,

progress on an ongoing, long term research program,

lessons from a completed project (including design mistakes!),

well-argued challenges to accepted ideas and methods,

an unexpected connection between two areas of programming
languages, or

a new line of research that builds off of other areas of
Computer Science or other disciplines.

Naturally, this list is not exclusive. In sum, submissions must lead
to a stimulating, thoughtful, or even (gently) provocative
discussion.
Looking at the Previous Proceedings may help.
(Essentially, imagine that you are applying for an
invitation to give a good keynote speech.)

SNAPL especially welcomes submissions by practitioners. They often
have difficulty presenting their work in the narrow format expected by
traditional conferences. In contrast, SNAPL’s openness of format and
emphasis on discussion should make it an attractive venue for them.

1.3Submission Requirements

Because SNAPL depends on presentation and discussion, attending
authors are expected to be good presenters and engaged
participants. Authors who attend are expected to stay for the entire
event and participate fully in discussion of papers other than their
own.

SNAPL submissions are not anonymized. We are interested, for instance,
in hearing from researchers who have conducted a particular project,
or built a particular language or system, over many years, and want to
provide their personal insights. In such cases, the identity of the
author is very relevant: the perspective of a creator is very
different from that of an outsider. As such, it is essentially
meaningless to try to anonymize such a paper.

Submissions must be formatted using the
LIPIcs style.
Authors really must follow this style, and it will save Dagstuhl
staff, the publications chair, and authors considerable pain to do so
from the start. Therefore, papers not formatted in this style will be
automatically rejected.

The initial paper should be a minimum of five and maximum of
eight pages, including supplements but excluding the bibliography in
the LIPics style. (That corresponds to 3–5 pages in ACM styles.)
Final contributions can be up to sixteen pages in length
(including supplements, excluding bibliography).

(Why the stark difference in lengths? Reviewers often ask for more
content, and it’s a bad use of authors’ time to determine what to cut
to make room for additional material. Authors may also want to include
additional results, supplementary material, etc. At the same time,
reviewer time is valuable, and we believe a good SNAPL contribution
can make its central point snappily; if it can’t do so in 5–8 pages,
it’s unlikely 16 pages will help.)

Note: Due to the current LIPIcs style, the author/affiliation
block can take a significant amount of space. While we need to conform
to the requirements of LIPIcs for the final submission, you are
welcome to creatively reformat this block for your submission to
minimize space usage.

1.4Submission Site

1.5Previous Proceedings

The proceedings volume of SNAPL 2019 will be published in the LIPIcs
series by Dagstuhl. For reference, you can peruse the proceedings from
SNAPL 2017
and
SNAPL 2015.

1.6Acknowledgement

SNAPL draws on the best elements of
many successful meeting formats, including the database community’s
CIDR conference;
NSPW in security;
the various Hot* conferences in systems; the practitioner-leaning
Strange Loop; Seminars hosted at Dagstuhl; Working Groups run by IFIP;
and *PLS regional programming language events.