The popl2022 from explorable-viz

Draft 2 of sections 1-4

Done/dropped:

3 intro: say what this section/definitions/results will achieve
3.1: why we define Sel_v{A}
3.2: revisit use of "interpret"
3.2: move GC motivation here from 3.5? (but also see 3 intro)
3.3: hole rule for forward-eval needs proper motivation
3.3: significance of mononicity theorems needs to be eastablished earlier (in 3 intro or 3.2)
3.5: intuitions about forward-eval need to be justified in terms of intuitions presented in section 1
2 intro: should motivate use of eliminators (and simplify/clarify what's already there)
2 intro: mention closures?
3.2: introduce forward/backward match/eval symbols here?
3.3: clarify use of grey subscripts in rules
3.3: widespread use of \leq etc on pairs needs signposting early
4: catchier title (suggestive of calculus of analyses -- maybe something about modalities of dependency)?
~~4 intro: stronger sell for idea of reusing/combining analyses from section 3~~
4.1: maybe the De Morgan dual figure could come later (at least, ask reader to ignore Fig. 11b initially)
4.1: state that we derive what is "necessary" from what is "sufficient" up front, and relate to linking?
fit into 21 pages

5-min promo video

The authors will be asked to prepare the video recording
of a 5-minute talk advertising their paper by January 2, 2022,
two weeks before POPL starts. These 5-minute talks will be
made available to the participants of both in-person and
virtual versions of the meeting in advance.

The precise instructions on this will be sent sometime in
December. I am sending this reminder so that you can make
a plan on this video recording.

Haskell-style arrays

Arrays with an API similar to Haskell arrays (except they’ll be strict, and not polymorphically typed).

Environment lookup lemma

Some to dos:

In the statement of the lemma on p.13, change the bulleted list to a numbered list for easy reference.
In the proof, make it clear which part of the theorem you’re proving (if the theorem has multiple parts).
To prove an implication A -> B you can suppose A and then deduce B – make sure that this structure is clear. So you should start with “suppose 𝜌 ◃_Γ (𝑧:𝑣)”.
Make it clear what the induction is “on” (the structure that is getting smaller at each step) – in this case the proof that 𝜌 ◃_Γ (𝑧:𝑣). This is also the subject of the case analysis.
Add rule names to environment lookup/lookupBwd definitions so that it’s always clear what rules are being used to pattern-match or construct proofs (lookup-head/lookup-tail might work or whatever you think conveys a reasonable intuition).
In the second case, the Γ subscript in the premise should be Γ’.
Also in the second case, you need to explain where the premise of the ▹ proof comes from. How do you know 𝜌′ ▹ (𝑧 : 𝑣)? That’s where you need the inductive hypothesis, which is a function of type (forall 𝜌 Γ 𝑧 𝑣 . 𝜌◃Γ (𝑧:𝑣) -> 𝜌▹(𝑧:𝑣). You will be “invoking” that function at a strictly smaller 𝜌, in this case 𝜌′. You need to establish 𝜌′ ▹ (𝑧 : 𝑣) using the IH and then use that fact to construct the (𝜌 ·(𝑧 :□))▹(𝑧:𝑣) derivation.
I suggest omitting the closing \intertext{\crossrule} and ending on \notag.

Also: it can be useful to restate the theorem (as you’ve done) as the point at which you present the proof. It’s also a pain to have to keep two copies of the theorem in sync. There’s a LaTeX package that makes it easy to restate lemmas; I’ll look into setting this up.

Initial pass over presentation

Skeleton of talk for practice run at PLUG, Tue 11 Jan.

Opening slide

title; authors + photos

Problem

understanding visual outputs means understanding what visual elements represent
- examples: various typical (= opaque) charts (see HPI talk)
can we do better?
- open source/open data help provide the raw materials but no insights into how things are related
- ~~what we would like is computational artifacts able to reveal their relationship to data interactively, on demand (without incurring programmer overhead)~~
two specific problems we would like to make progress towards; first is linking outputs to inputs in a fine-grained way
- author just writes regular functional viz code -- bar chart example
- "round-tripping" properties important for trust/correctness (here: sufficiency)
second is linking outputs to other outputs in a fine-grained way (and seeing the relevant data) -- line chart example
- for the forward analysis here, we care about necessity, not sufficiency

Solution (part 1)

Solution (part 2)

also want to understand how outputs relate to other outputs
- nature of "forward" question changes: not what x is sufficient for but what x is necessary for
- turns out our more general notion of selection can help here too, because it supports negation
De Morgan dual
- using negation (complement), can formulate "necessary for" in terms of "sufficient for"
- think of this as inverting the direction of the GC (by turning meet-preserving into join-preserving and vice versa)
- ~~more generally: composing a GC with itself~~
demo: linking example

Closing slide

conclusion & future work
- link to f.luid.org
- future work: expression provenance

Done/dropped:

Substantive revisions

Define slicing functions directly

Replace the current inductive/relational definitions of forward and backward slicing, and subsequent definition of Galois connections by domain-restriction, by direct recursive definitions of the Galois connections. This should make the relationship between the definitions and the metatheory clearer, and free up some space. It will require reworking all the proofs.

All forward-slicing functions for desugaring will need to be given separately from the desugaring relation – this will add about 1.25 pages of new definitions, but there should still be a net saving in space.

Reinstate nested patterns

Mutual recursion and generalised let

Reinstate rules for mutual recursion from previous draft. Also consider generalised let, to allow expressions like let (x, y) = e in e', which require the notion of a “singleton” eliminator. Put these in the appendix.

appendix:
- mutual recursion
  - syntax and typing rules
  - “close defs” operation, with fwd and bwd slicing
  - revised app rule, with fwd and bwd slicing
- non-recursive functions
  - syntax and eval rules
  - fwd and bwd slicing rules
- ~~let f σ~~ – actually no advantage in this form over letrec f σ
- generalised let
  - singleton eliminators
  - syntax, semantics and slicing rules for generalised let
main body:
- replace recursive function literals by let rec
- non-recursive function literals (lambdas) – move to appendix
- revert to zipper-based “match” traces; drop “partial” eliminators from core

First pass over core language

Anonymised paper build omitting appendices

Build script and macros to build submission version:

collate-examples.sh to run optionally (but always on GitHub), snapshot of examples in repo
~~macro for proof references~~ difficult – see note below
two orthogonal conditionals: anonymous and appendices (although we only need 3 of the 4 cases)
set anonymous whenever @ACM@anonymous is set
macro for language name
options for build.sh, with default
GitHub Action to build all configurations
submission version to enable review option (for line numbers)

Final tweaks/considerations

~~section 3: better notation for forward/backward environment lookup~~
~~It would be nicer to have countries as columns (see below)~~
remove vectors from core language?
remove partially applied primitives?
~~drop mutual recursion in favour of single recursive function~~
~~round-tripping figures at end of section 3 (related to section 4)~~

Countries as columns:

| Year | Type | USA | China | Germany |
| — | — | — | — | — |
| 2015 | Bio | 12 | 34 | 56 |
| 2015 | Hydro | 78 | 91 | 11 |
| 2015 | Solar | 12| 13 | 14 |

Then we can have just a single table and two charts. In one chart, we use RED and in the other BLUE. We then highlight some cells in RED and some others in BLUE.

Backward projectional slicing

bwd-eval rules
bwd-match rules

Slicing rules for desugaring

For explorable-viz/fluid#278 and explorable-viz/fluid#277 we need syntax sugar. Slicing needs to be defined for desugaring.

syntax of surface language (as separate figure), including explorable-viz/fluid#115
desugaring definition, with auxiliary function to totalise an eliminator
forward slicing rules
backward slicing rules
~~prove that desugar_fwd and desugar_bwd form a Galois connection~~ – see #52

Draft 2 for PLUG

convolution demo
- record
- speed up and export
- example with different boundary method
bar chart/line chart demo
- record
- speed up and export
miscellaneous
- trial Zoom recording with .mov playback
- trial playback of recorded talk over Google Meet
- explain matrix convolution
- explanations for convolution boundary methods
- change Fluid text on website to “data-linked visualisations”
- (recorded) dry run to identify missing bits of exposition (45 min)
“Making sense of visual outputs”
- better summary: can we use PL, data provenance, dynamic analysis to help here?
- make Chiang Mai chart much larger
- better title: “provenance-aware” data visualisation?
- legends are only comments, they have no semantic meaning
“How can we improve on this picture?”
- move to closing slide; add layer that shows input/output relationship
- shift from “run once” execution to living relationship between input and output
“Goal 1: Fine-grained linking of outputs to inputs”
- mention our own programming language
- explain round-trip (sufficiency) in terms of reproducibility/trust
- ~~output no longer oblivious to how it was computed from input~~
“Goal 2: Linking outputs to other outputs”
- unselected line chart on right?
- include legends on both charts (but point out that year is not mentioned on left)
- what is the nature of the relationship on the right? is the same as the one on the left?
- no: “needs” is wrong direction, and “suffices for” has wrong “modality” (USA data insufficient)
“Prior work: Galois slicing 1”
- present as an example of dynamic program analysis with the desired round-tripping properties
- ~~explain what example program does~~
- by “input” I mean to include program as well
- new code layer without blue shading
- capture input/output we care about by erasing irrelevant subtrees; add layer to illustrate
- allude to role of trace
- give Galois connection intuition on this slide (monotonicity; increasing/decreasing)
“Prior work: Galois slicing 2”
- perhaps merge with round-tripping part of previous slide (use needs/suffices for as f and g?)
- significance of meet/join preservation
- talk about ordering relation on slices
“Prior work: Galois slicing 3”
- ~~for example, I can’t easily select 0.6, but only the expression that surrounds 0.6~~
- use brown as the erasure colour
- use summary of two steps to simplify explanation
- new title: “Differential” slicing
“Prior work: Galois slicing 4”
- ~~merge into previous slide~~
- 2 and 3 not in differential slice because they appear in both slices
- again the “modality” isn’t the right one
“Galois dependencies”
- Pos(e) -> Paths(e)?
“Representing selections”
- drop hole
- simplify text: just α in A represents selection state (whether that path is included)
- useful to allow A to be an arbitrary lattice but most concretely this can just be Bool
- erase -> shape?
- mention no annotations on operators or closures
“Forward and backward dependency analysis”
- ~~give flavour of analyses for primitives, structured data?~~
“Demo 1: Matrix convolution”
- highlight inputs (image, filter)
“Goal 2: Linking outputs to other outputs”
- “sufficient for” in purple?
- “negate” in neither green nor purple?
“De Morgan Duals 2”
- replace α, β by needs, suffices for?
- Galois connections compose component-wise
- the composite GC also has a dual which goes from V2 to V1
- tell us how V1 and V2 compete for resources
“Demo 2: Brushing and linking”
- ad hoc support for this in existing viz libraries; automation can be ubiquitous and robust
- also “data transparent”
miscellaneous
- record demos again, omitting unnecessary mouse movements
  - convolution.mov
  - linking.mov
    - on LHS need to select Germany as well
- blank layer at the top of each slide, for sketching on; reset layer states
- fresh practice copy of slides

Initial draft

Initial draft prior to meeting with Benjamin on 30 May.

Vis 2019 LaTeX template
edit template into document skeleton
import hand-drawn sketches from Tomas
intro blurb, adapted from TPS proposal
rough pass over abstract
rough pass over intro
flesh out and send to Benjamin at end of Weds

Comments on Section 1&2

I read through the first two sections and find them quite good. There are a few comments which I detail below. But the main concern is probably that it is 10-pages long.

Draft 1

Other subtasks:

#4
#116
evaluation/toolkit
#117
#168

Anonymised supplementary material (available to reviewers along with paper):

Provisional section lengths (25 pages total, 6 sections, so ~4 pages per section on average):

section	target length?	current length
1. intro	4 pages	3.5
2. core calculus	5 pages	5
3. dependency analysis	8 pages	8.5
4. evaluation/toolkit	4 pages	4
5. surface language	3 pages	4
6. related work/conclusion	1 page	0
TOTAL	25 pages	25

Piecewise definitions

The implementation allows piecewise function definitions by pattern-matching, albeit without guards. These are checked for well-formedness (mergability) and translated into eliminators, at parse-time. As we integrate desugaring into the implementation, we should migrate this process into the desugaring phase, and retroactively formalise the process that turns a (well-formed) sequence of equations with patterns on the LHS into an eliminator.

@min-nguyen Here’s a breakdown of this task. Once this is formalised, it should be relatively straightforward to adjust the implementation to match the formalisation. The main thing to change will be that in the implementation of piecewise definitions, the parser currently use a “nested” (eliminator-like) notion of pattern, that also combines a continuation. In the formalisation of piecewise definitions we will reuse the (more conventional) notion of pattern defined for the surface language, with a separate continuation. Once we’ve changed the current implementation to work like this, we’ll be in a good position to migrate over to the surface language.

Extend the syntax of raw surface terms with a let f \vec{c} in s construct for defining (recursive) functions. We can omit the rec keyword and just assume all functions are recursive. Metavariable c ranges over the clauses which define f. In the concrete syntax, we expect each clause to start with f. But defining the abstract syntax as let \vec{f c} in s would be a bit redundant.
A clause is a non-empty sequence of equations of the form \vec{p} = s. I suggest making the non-emptiness explicit in the definition.
Give a typing judgement for clauses, using the typing rule for patterns and the typing rule for (surface) terms.
Give the additional typing rule for let f \vec{c} in s. Look at how recursive functions are dealt with in the core language. The main extra consideration here is that you will need to type-check each clause; this can be done using a universally-quantified premise of the form ∀i ∈ dom{\vec{c}}. ... (remember that a vector can be thought of as an indexed family or partial function, like we were discussing the other day; dom will retrieve the index set/domain).
Give the desugaring rule for let f \vec{c} in s, which will defer to an auxiliary function merge \vec{c} = σ.
Defining merge is probably best done in two stages. First, define a function elim p κ = σ which turns pattern p and continuation κ into an eliminator, defined mutually recursively with a function elim o κ = σ which does the analogous thing with a list pattern “rest”. An important detail is how elim represents the partiality of the resulting eliminator. Until now we have had eliminators with missing branches. For various reasons, I think it will be easier if we require all branches to be present (e.g. [] and (:)) but allow the continuation to be a hole (□). In particular this will allow the merge of partial eliminators via the join (∨) operation given in Fig. 12.
Second, define merge so that (extensionally speaking) it first maps elim to the list of clauses, promoting each into an eliminator, and then folding ∨ over the result. Both of these operations are partial, although in the formalism we can assume the clauses are well-typed, which eliminates the most egregious problems.
The ∨ operator for eliminators is mostly sufficient as it is, except that we should define an overload for expressions, where e ∨ e’ is defined (and equal to e) only when e = e’. In other words, by the time the merge operation gets down to the expressions at the end of each clause, they can’t be merged unless they are equivalent. (This is actually more general than any practical language would permit, since it allows “duplicate” clauses of a definition as long as they agree syntactically. But it’s harmless and makes the formalism a bit easier.) We should also define e ∨ □ to be e and σ ∨ □ to be σ.
It should be straightforward now to add back match..as back into the surface language, using the same machinery. The syntax should be match s as \vec{c}; the typing and desugaring rules should be easy. In the concrete syntax implemented by the parser, we allow -> instead of = in the clauses, but we needn’t concern ourselves with this difference in the abstract syntax.

First pass over dependency analysis

Done/dropped:

What is the primary purpose of the calculus? To track data dependencies.
Core approach: treat data type of terms as a functor so we can attach usage information to certain subterms. Maybe make that explicit, e.g. Expr a where a is the type of the annotations.
We will constrain a to be a lattice. Say what a lattice is and why it might be relevant to the idea of selection introduced in section 1.
Point out that we can recover (something isomorphic to) “normal” syntax by instantiating Expr with unit (trivial one-point lattice). Expr Bool (Bool as 2-point lattice with the usual Boolean connectives) gives a basic notion of selection. But we can also imagine computing 2 selections simultaneously (as Expr (Bool × Bool)). (It may be premature to go into too much depth here, but we will at least need an example of Expr Bool and how it can represent a data selection.)
We might need to switch our use of tt and ff in the semantics to ⊤/⊥ (if we want to remain abstract in an arbitrary lattice).
We also have annotations on (some) terms forms – those that relate to data. This allows us to trace back to the source code responsible (we will revisit this in section where we consider a richer surface language).
~~(@rolyp) Move to functional definitions of fwd/bwd slicing~~
Forward/backward dependency analysis:
- New notation for “unannotated” terms
- define “selections” w.r.t. a fixed unannotated term, explain how this forms a lattices too

Suspected typo in Figure 9

The forward "record" and "project" rules seem to be given the wrong names.
Figure 5 appears after figure 6.

Final version

Minor corrections.

Artifact submission

Subtasks (dealt with elsewhere):

explorable-viz/fluid#478
explorable-viz/fluid#480
upload to Zenodo
complete ACM artifact form (see email of 9 Nov)

Slicing rules for first-class primitives

The slicing rules for first-class binary operations, which include partially applied operations, are non-obvious enough to need writing down. In the old formalism only unary operations were first-class; for the present paper we might want both traditional operation syntax and first-class operations.

generalise + to arbitrary binary operation
expression form for binary operations, with evaluation and slicing rules
generalise primitive values to include unary ops; binary primitives are curried
app rule to cover (potentially partially applied) binary operations in the function position
fwd slicing rule
bwd slicing rule(s)
k to range over variables and operator names?

Eval/uneval Galois connection

25 May - Notes

Characterize what is this "understanding" of program that we're aiming for - a general thing of which visualization is one example (it would be nice if abstract started from this general thing)

First pass over surface language

Explain/motivate the surface language and relevance to the overall problem. Some definitions will have to move to the appendix.

Code/example todos:

example that shows constructed values consuming constructed values (e.g. tree nodes needing list nodes)
verify annotations on values prettyprinted correctly
- consolidate prettyprinting special cases on pairs and lists
- prettyprint lists as nil, cons nodes
- add highlightIf logic for constructors

Done/dropped:

Formalise primitives broadly as implemented

The current formalisation of primitives doesn’t allow for operations that don’t depend uniformly on all their arguments (e.g. operations with annihilators). Also, the current formalisation doesn’t easily accommodate desugaring of binary application into nested application of first-class primitives, because it requires binary operators to be annotated (which they currently aren’t). This second problem is related to the first, because we use the annotation on the operator to accumulate the (conjunction of) the annotations on the arguments. We should formalise primitives properly, albeit without all the complexity of the implementation (e.g. overloading, and operations defined on structured values).

move binary application to surface language
introduce partially applied primitives into the value syntax
primitives should accumulate args until application is saturated, as per impl
require each primitive to specify a fwd and bwd slicing operation
~~introduce a “primitive application” helper so we don’t need two primitive rules per judgement?~~

Reviewer response

Due by midnight Wed 8 Sep AoE = 1pm 9 Sep BST (check).

fix f.luid.org/new build
add explanatory text and ensure reachable from f.luid.org
import reviews into repo
first pass over response, quoting relevant review comments
second (condensed) pass, replacing quoted comments by topic summaries
third pass based on Meng's feedback
finalise and submit

Tidy-up pass over theorems/proofs

Consolidation pass before next Thursday’s meeting.

separate clause lemma for list-rest patterns
check each proof for consistency with \eq handling in associated definitions
each proof to reference the theorem (part) it proves
each theorem to forward reference the relevant proof (but see #104)
restate the theorem before the proof? (see objects-as-automata for how to do this)
reduce space around \intertext{\crossrule}?
standardise on use of parentheses and capitalisation in rightmost column
upload new version to arXiv

Typing rules for projectional approach

reinstate two projectional forms of cons/pair slicing
type slices
typing rules
projection for contexts and types

Switch to 1-dimensional arrays

The current matrix formalisation is less general and more complex than it could be – 1-D vectors would probably be better.

First pass over introduction

Plan of introduction/overview

Introduction

Identifying the problem

visualisations central to communicating science and public policy, but easy to misuse/misinterpret
can improve this by making them more explorable – usually done through brushing & linking (and lots of viz frameworks support this: altair, vincent, bqplot, shiny, plotly, Glue)
but there are various problems with this – automated linking usually only possible for visualisations provided by the library, or where the user specifies explicitly how things are to be linked
can we solve this problem using PLT, so that programmer just writes purely functional visualisation code, and the infrastructure does the linking? this would make linking pervasive, automatic, and mathematically robust

Towards a solution: Galois slicing for linking visualisations

the above requirements suggest that dependency analysis may be able to help
Galois slicing in particular is a technique which lends itself to the bidirectional aspect of the problem
namely: when two charts are “cognate” (depend on common data), we can link them by slicing backwards from one chart to identify the needed data, and then forward to see the parts of the other chart that depend on that data

Problems with existing approaches (1)

however, prior work on Galois slicing considers a slice to be a “partial term” or context (term with holes) – which isn’t a suitable notion of selection – one cannot formulation the question “what is needed for Y?” where Y focuses on an arbitrary part of the output
prior work does propose differential slicing as a notion of selection, but this underapproximates the required dependency information
- idea of differential slicing is to “focus” on a subtree v, compare the slice with respect to the “spine” which picks out v, and the slice with respect to that same spine with v included
- if any of the input needed for v is also needed to compute the spine, this won’t show up in the differential slice (simple example with let/pair)
to avoid this problem we will formalise the notion of selecting elements of interest directly in the Galois framework

Problems with existing approaches (2)

we also need to be able to ask a different but related kind of question: “what depends on X?”

Overview/motiving example(s)

we will break down our problem of linking cognate visualisations into two subproblems: (a) what data does some part of V1 depend on, and (b) what parts of V2 depend on that data?
problem (a) can be illustrated by considering a familiar example: matrix convolution
- when we select an output cell, we can see what input cells and kernel cells were needed
- there is an implicit dual to this question: what parts of V2 depend only on some data? i.e., what parts of V2 is that data sufficient for?
- these questions (“what resources are needed for Y?” and “what can we do given resources X?”) are dual (adjoint)
problem (b) is distinct from problem (a) but also from its dual, and can also be illustrated using matrix convolution
- when we select an input cell X, we can see what output cells needed it (in general X may not be sufficient for any cells, but there may be many cells which need it)
- we can formulate this problem by flipping the polarity of (negating) the input, so that we have all resources apart from X; anything we can no longer compute must depend on X
- in turn, the negation of this (the output) is exactly the things that depend on X

Some to dos:

(@rolyp) abstract
- alternative to “slicing” terminology (e.g. Galois dataflow, Galois data dependency, Galois provenance..)
(@tpetricek, @rolyp) initial plan for intro/overview (see notes in comments below)
- ~~example: matrix convolution (some nice lecture notes on convolutions and kernels)~~
- example: brushing-and-linking

Explore grant options

email everyone re. TPS funding
chase feedback on URF application
~~check with EPSRC re. co-investigator vs. researcher co-I eligibility for me~~

Investigate UKRI Future Leaders Fellowships:

~~check ATI eligibility~~
get back to Chris Williams re. Edinburgh application
~~other possible host institutions (Bristol, Glasgow?)~~

See:

Turing policy on REG grant applications

Projectional argument slicing

It should be possible to project away unused arguments, analgously to how we project away unused parts of tuples. There may be a difficulty projecting away the last argument to a function and preserving “application-hood”; might be possible to deal with this in the definition of projection, by specifying that unneeded final arguments project to the unit value, rather than being erased.

Auxiliary lemmas for desugaring Galois connection

Prove the auxiliary lemmas at the beginning of the appendix. @min-nguyen We’ll pick these up in the first week of May.

First pass over negation section

Source code for convolution example

Script to download .fld source files from the Fluid repo and put them somewhere the LaTeX build expects to find them.

PLUG practice talk

Dry run
- have both .mov files open full-screen and rewound to beginning
- ~~reset layer states on all slides~~
- record
Presentation
- less is more when explaining
- remove 2015 highlight from Goal 1
- "brushing and linking" on Goal 2
- reorder layers on Goal 2
- clarify Galois slicing has the needs/sufficesFor property
- define two analyses over a trace of e => v
- two views of the same data
- new copy of "raw" slides
Bits to rehearse
- Galois slicing slide 1
Topics I may need answers to or to be able to expand on
- data dependency can be on constants in the program too
- other data may be deemed irrelevant because it is only involved in the "why", not the "what"
- different kinds of question one might ask; this approach allows them to be asked independently
- “general case” (composing a GC with its dual)
- what are the arguments to method in the convolution example?

PLUG prep:

have both .mov files open full-screen and rewound to beginning
reset layer states on all slides
charge Apple Pencil and iPad
mic on and nearby
brown as highlight colour

First pass over related work/conclusion

Records

It’s hard to do data science examples without records. The following should generalise the current pair rules, which will now be subsumed by a desugaring into records:

record types
record eliminators – make sure singleton record eliminator distinguishable from variable eliminator
record constructors { \vec{x: e} } and corresponding value form
match and trace forms
typing rules for values, expressions and eliminators
pattern-matching and evaluation rules
leq and join definitions
forward and backward slicing for pattern-matching
forward and backward slicing for evaluation

The main technical questions are:

Do record eliminators “nest” in the way that pair eliminators currently do. Probably yes, but that might look a bit weird: a record eliminator will be a “partial matcher” for the first field only. Experiment with this first.
W.r.t. to annotations (and construction/deconstruction), should we treat records as heterogeneous lists? Or should there be a single annotation for the entire record?
In our examples, pairs are datatypes, not record types – need to rethink the desugaring idea

Desugaring:

surface form for pairs (e, e’) and typing rule
retain pair patterns, but pair pattern typing now yields a record type
record patterns, plus typing rule
disjoint join (record case to generalise pair case)
desugar fwd and bwd to { fst: e, snd: e’ }
clauses desugaring: pair pattern to record eliminator, plus record pattern rule (fwd and bwd)
totalise: pair case to use record eliminator, plus record pattern rule (fwd and bwd)
“empty record” macro
experiment with parentheses around all records?

Projection:

record projection expression, typing and trace form
evaluation, fwd and bwd rules

We may end up defining record operations that won’t be typable in the naive type system we give in the paper. But most of our prelude isn’t typable in that type system either, because the type system lacks polymorphism.

Camera-ready copy (final version)

please omit all packages/commands that interfere with default length, e.g. \raggedbottom
second-level and third-level headings: headline-style capitalization should be used
p. 16: undefined figure reference
caption missing for figure on p. 17
~~References: Several DOIs are missing~~
author-year-style citations should be used, not numeric citations
p. 27 should be filled with references, there is no need to start a new page for this section
Fig. 2 should not reach into the right margin outside the text area
please consider numeric order for position of Figs. 12 and 13 (i.e. Fig. 12 above Fig. 13)
p. 1 seems too short, copyright information and 'Authors’ addresses' are not in correct position

Please take the following small issues into your consideration
(cf. instructions page).
https://www.conference-publishing.com/Instructions.php?Event=POPL22MAIN&Paper=9a290741459e0754e32a4c254aa860d757e4a05d

Please make sure to use the default length of all pages.
Page 1 seems to be too short, the copyright information and the 'Authors’ addresses' are not in the correct position.
Please omit all packages and commands that interfere with the default length.
\raggedbottom looks suspicious.

Second-level and third-level headings: Headline-style capitalization should be used.
Capitalize:

first and last word, first word after a colon

all major words (nouns, pronouns, verbs, adjectives, adverbs)
Lowercase:

articles (the, a, an)

prepositions (regardless of length)

conjunctions (and, but, for, or, nor)

to, as
Hyphenated Compounds:

always capitalize first element

lowercase second element for articles, prepositions, conjunctions
and if the first element is a prefix or combining form that could not stand by itself

References: Author-year-style citations should be used in this ACM style, not numeric citations.

Page 27 should be filled with references, there is no need to start a new page for this section.

References: Several DOIs are missing. Please consider adding them.

On page 16, there is an undefined figure reference in the text.
The caption is missing for the figure on page 17.

Please consider a numeric order for the position of figures 12 and 13
(i.e. Fig.12 above Fig.13).

Figure 2 should not reach into the right margin outside the text area.

Please make the proposed changes and re-submit your paper if possible within three workdays.
(Please use the submission link from the author-kit e-mail, do not send by e-mail.)
Submission link:
https://www.conference-publishing.com/submission.php?Event=POPL22MAIN&Paper=9a290741459e0754e32a4c254aa860d757e4a05d

Desugaring Galois connection

Show how the fwd and bwd desugaring slicing rules form a Galois connection (for a given program). Tasks:

Done/dropped:

Other useful points of reference:

“set of paths in a term” exposition in 3.2 of FPTETW
methodology summarised in 2.3 of IFPTETW

HPI presentation

Background slides to motivate/frame demo:

salvage what I can from Shonan slides
slide with 3 or 4 papers listing problems with data visualisations
research hypothesis: we need to make visualisations more transparent and explorable
relate to linking and brushing in D3, etc
example of whence/whither questions
Galois connection diagram from poster
revise "technical goals" slide to summarise main challenges
dry run 1

Hole rules

Holes are still need for the slicing algorithm to be tractable (else environment merging is exponential), even though they are equivalent to a term where all annotations are set to false (where no paths have been selected). It probably makes sense to add explicit rules for hole; they will overlap (in a “compatible” way) with the existing rules, and so are technically redundant, but will be helpful for implementation.

It turns out this isn’t straightforward (and in fact, nor is the implementation; it will need similar fixing). The issue is that forward-slicing of pattern matching, when the scrutinee is a hole, requires knowing the prefix of the value that was original matched (a “traced match”, or what we simply call a “match”). In turn this means forward slicing requires a trace. We can’t just assume that pattern-matching a hole produces a hole for the evaluation of the continuation (as with our previous approach); that isn’t true, because once control transfer to a different function context, we’re free to start constructing values again.

Other fixes unrelated to holes:

(experimental) family notation for join/meet of multiple annotations
drop “non-empty” side-conditions (implicit)
missing annotations on identifiers in applications
missing annotations on guard qualifiers (and fix syntax)
missing annotations on [] in guard qualifiers
list-comp-decl rule (inconsistently) included β (previously α_3) into the demand on the qualifier
totalise should take an annotation to attach to any constructed nodes
untotalise should return the (join of) the annotations on any constructed nodes

Mutual recursion lemma

Prove that the fwd/bwd definitions for closeDefs form a GC.

explorable-viz / popl2022 Goto Github PK

popl2022's People

Contributors

Stargazers

Watchers

popl2022's Issues

Opening slide

Problem

Solution (part 1)

Solution (part 2)

Closing slide

Plan of introduction/overview

Introduction

Identifying the problem

Towards a solution: Galois slicing for linking visualisations

Problems with existing approaches (1)

Problems with existing approaches (2)

Overview/motiving example(s)

Some to dos:

Recommend Projects

Recommend Topics

Recommend Org

Jobs