larrytheliquid / generic-reuse

Source code accompanying the draft paper "Generic Zero-Cost Reuse for Dependent Types"

Generic Zero-Cost Reuse for Dependent Types

Cedille code accompanying the paper draft (available on arXiv) authored by Larry Diehl, Denis Firsov, and Aaron Stump.

This is the generic version of our previous manual reuse work, where identity functions are defined via definitional equality, rather than propositional equality.

We describe the directories containing our code below. As in the paper, program reuse corresponds to non-dependent function type reuse, proof reuse corresponds to dependent function type reuse, and data reuse corresponds to fixpoint type reuse.

Evaluating This Work

The Cedille type checker, needed to evaluate this work, is available here.

The artifact branch has a document that explains how to work with Cedille for the purpose of evaluating this work. The master branch is only ahead of the artifact branch in minor ways, so the document should apply to the master branch as well.

The artifact branch includes a pre-released version of Cedille, if you don't want to separately git clone and install it, but I suggest installing the now open source Cedille instead (following these installation instructions).

Alternatively, if you don't want to manually install anything, there is a Virtual Box image of the artifact branch that you can get from here, by clicking the "Source Materials" tab on the bottom and downloading the zip file.

GenericReuse

This directory includes our primary contributions, the generic zero-cost reuse combinators for the following types:

• Functions (forgetful allArr2arr & allPi2pi)
• Functions (enriching arr2allArrP & pi2allPiP)
• Fixpoints (forgetful ifix2fix)
• Fixpoints (enriching fix2ifix & fix2ifixP)

The auxiliary combinators also appear here.

Examples

This directory includes reuse examples via our combinators:

• Program Reuse of append and Proof Reuse of associativity
  • forgetful appV2appL & enriching appL2appV
  • forgetful assocV2assocL & enriching assocL2assocV
• Data Reuse of vectors and lists
  • Forgetful v2l
  • Enriching l2v
• Data Reuse of unchecked/raw and checked/typed STLC terms
  • Forgetful t2r
  • Enriching r2tP
• Program Reuse of STLC step function (enriching stepR2stepT)
• Program Reuse of STLC substitution function (enriching subR2subT)

Datatypes

This directory includes the algebraic list and vector datatypes, and their schemes, defined using generic Mendler-style fixpoints:

• Lists Scheme (ListF)
• Lists (List)
• Vectors Scheme (VecF)
• Vectors (Vec)
• Raw Terms Scheme (RawF)
• Raw Terms (Raw)
• Typed Terms Scheme (TermF)
• Typed Terms (Term)

The derived definition of Nat (in terms of the scheme NatF) also appears here, as well the types Tp of STLC (and their scheme TpF).

IndexedMendlerInduction

This directory imports the generic datatype development (via efficient Mendler-style fixpoints) by Firsov et al.:

• Non-Indexed Fixpoints (FixIndM)
• Indexed Fixpoints (IFixIndM)
• Identity Mappings (IIdMapping)

It also includes the generic derivation of induction (iindFixIndM), as well as other technical devices.

Base

This directory includes base or "prelude" definitions, like the Unit and Sigma types. It also includes IdDep, the type of dependent identity functions.

generic-reuse's Issues

Add the non-dependent folds for the Base types.

How can I typecheck these examples?

Is there a typechecker which can verify all these examples? Is it this one: https://github.com/MaiaVictor/cedille-core ? If yes, how can I use it? A few lines about this in the README would be appreciated 😉

Difference between definition of AssocV in paper vs code

In the paper, AssocV is defined very concisely:

AssocV ◂ AppV → ★ = λ appV.
∀ A : ★. ∀ n : Nat. Π xs : Vec A n.
∀ m : Nat. Π ys : Vec A m. ∀ o : Nat. Π zs : Vec A o.
appV (appV xs ys) zs ≃ appV xs (appV ys zs)).

In the code, however, it depends on four auxiliary definitions:

AssocV4 ◂ AppV ➔ Π A : ★.
Π n : Nat. Vec · A n ➔ Π m : Nat. Vec · A m ➔ Π o : Nat. Vec · A o ➔ ★ =
  λ appV : AppV. λ A : ★. λ n : Nat. λ xs : Vec · A n.
  λ m : Nat. λ ys : Vec · A m. λ o : Nat. λ zs : Vec · A o.
  {appV (appV xs ys) zs ≃ appV xs (appV ys zs)}.
AssocV3 ◂ AppV ➔ Π A : ★. Π n : Nat. Vec · A n ➔ Π m : Nat. Vec · A m ➔ ★ =
  λ appV : AppV. λ A : ★. λ n : Nat. λ xs : Vec · A n. λ m : Nat. λ ys : Vec · A m.
  ∀ o : Nat. Π zs : Vec · A o. AssocV4 appV · A n xs m ys o zs.
AssocV2 ◂ AppV ➔ Π A : ★. Π n : Nat. Vec · A n ➔ ★ =
  λ appV : AppV. λ A : ★. λ n : Nat. λ xs : Vec · A n.
  ∀ m : Nat. Π ys : Vec · A m. AssocV3 appV · A n xs m ys.
AssocV1 ◂ AppV ➔ ★ ➔ ★ = λ appV : AppV. λ A : ★.
  ∀ n : Nat. Π xs : Vec · A n. AssocV2 appV · A n xs.
AssocV ◂ AppV ➔ ★ = λ appV : AppV. ∀ A : ★. AssocV1 appV · A.

Is this because the version in the code is more generic than the one in the paper, or are these four auxiliary definitions strictly necessary to make it work? Also, could you share some intuition on what they're good for?

change x-vs-y naming convention for fix combinators

Also change it in the examples, and in the Tex.
Currently x and xs are used, when sometimes y and ys makes more sense.

Also update index-index branch.