Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.compilers > #1858 > unrolled thread

CfP: 1st Workshop on Incremental Computing 2017 (Barcelona, June 2017)

Started byMatthew Hammer <Matthew.Hammer@Colorado.EDU>
First post2017-04-19 19:27 +0000
Last post2017-04-19 23:03 +0000
Articles 2 — 2 participants

Back to article view | Back to comp.compilers


Contents

  CfP: 1st Workshop on Incremental Computing 2017 (Barcelona, June 2017) Matthew Hammer <Matthew.Hammer@Colorado.EDU> - 2017-04-19 19:27 +0000
    Re: CfP: 1st Workshop on Incremental Computing 2017 (Barcelona, June 2017) Kaz Kylheku <686-678-9105@kylheku.com> - 2017-04-19 23:03 +0000

#1858 — CfP: 1st Workshop on Incremental Computing 2017 (Barcelona, June 2017)

FromMatthew Hammer <Matthew.Hammer@Colorado.EDU>
Date2017-04-19 19:27 +0000
SubjectCfP: 1st Workshop on Incremental Computing 2017 (Barcelona, June 2017)
Message-ID<17-04-019@comp.compilers>
CfP: 1st Workshop on Incremental Computing (IC) 2017
====================================================

The First Workshop on Incremental Computing (IC) will provide a space
where PL enthusiasts and researchers can come to discuss incremental
computing problems and solutions.  It is co-located with PLDI 2017,
ECOOP 2017, DEBS 2017, and Curry On, in Barcelona Spain:

  http://pldi17.sigplan.org/track/ic-2017-papers

Background
-----------

A computation is incremental if repeating it with a changed input is
faster than from-scratch recomputation. Incremental computations can
be found across a wide range of computing domains, and thus across
many areas of computer science. Consider the following examples:

- spreadsheet evaluation,
- the database view maintenance problem
- incremental compilation management
- the rendering pipeline of web browsers
- artificial intelligence and planning in games and in robots
- motion simulation in computational geometry
- interactive features of integrated development environments
  (including incremental parsing, typing, verification and testing).

In each problem domain, practitioners engineer incremental
computations to fulfill a practical need: Without these techniques, a
system may be too unresponsive or inefficient to be useful, or at the
very least, its utility would degrade.

In the area of PL, researchers are particularly interested in
language-based approaches to incremental computation. In contrast to
the algorithms community that often studies each incremental problem
in isolation (e.g., incremental convex hull), PL researchers study
large classes of incremental programs that are defined by a
programming language. The scope of this programming language may vary,
and be intended as general-purpose or domain-specific. In either case,
the language and associated algorithmic techniques express the
behavior of many incremental programs.

Keynote Speaker:
-----------------

Nicholas Matsakis (Mozilla; Rust core team):
http://conf.researchr.org/profile/ic-2017/nicholasmatsakis


Call for talk proposals:
------------------------

IC solicits talk proposals from the community. A good talk at IC
probably consists of one or more of the following:

 - explain an existing language or framework for incremental computing,
 - outline an incremental computing domain in detail, highlighting challenges,
 - outline a new incremental computing problem, or problem domain,
 - propose a new language or framework for incremental computing,

This list is not exhaustive, but merely suggestive.

Submissions for talks: Authors will submit at most a 2-page PDF
document, in at least 10pt font, printable on US Letter paper. Authors
are free to include links to multi-media content such as github
projects, youtube videos or online demos. Reviewers may or may not
view linked documents (it is up to authors to convince them to do so
in their 2-page submission). Authors should not assume that reviewers
will be experts in the particular area of the submission b they will
most likely not be. All submissions should be accessible to a wide
range of programming language researchers.

Submission will be handled through HotCRP:
https://ic17.hotcrp.com/

Reviewing of submissions will be very light. Authors should not expect
a detailed analysis of their submission by the program
committee. Accepted submissions will be posted as is on this on this
web site. By submitting a document, you agree that if it is accepted,
it may be posted and you agree that one of the co-authors will attend
the workshop and give a talk there. There will be no revision process
and no formal publication.

[toc] | [next] | [standalone]


#1859

FromKaz Kylheku <686-678-9105@kylheku.com>
Date2017-04-19 23:03 +0000
Message-ID<17-04-020@comp.compilers>
In reply to#1858
On 2017-04-19, Matthew Hammer <Matthew.Hammer@Colorado.EDU> wrote:
> CfP: 1st Workshop on Incremental Computing (IC) 2017 ...

> A computation is incremental if repeating it with a changed input is
> faster than from-scratch recomputation. Incremental computations can
> be found across a wide range of computing domains, and thus across
> many areas of computer science. Consider the following examples:
>
> - spreadsheet evaluation,
> - the database view maintenance problem
> - incremental compilation management

Just adjusted an old Makefile recipe this morning to detect that a new
y.tab.h after executing "yacc parser.y" is exactly the same as the previous
y.tab.h, and so we can just restore the previous one, thereby avoiding
recompilation of everything that depends on y.tab.h.

Most parser changes are localized: they do not introduce new tokens, nor
change the YYSTYPE node structure. If these changes do not take place,
then the callers of yyparse() don't have to be recompiled.

(We wouldn't have to do hacks like this if make relied on file hashes
rather than modification time stamps, needless to say.)

In any case, cheers to incremental computing.
[A long time ago when I was editing the Journal of C Language
Translation, we had a series of articles on incremental parser
generation.  It was quite good, look at the change in the grammar,
figure out what the change in the state machine would be.  Usually
small changes produced small changes and there was a large win
over recompiling the whole thing. -John]

[toc] | [prev] | [standalone]


Back to top | Article view | comp.compilers


csiph-web