jacquescarette / theoriesanddatastructures

Showing how some simple mathematical theories naturally give rise to some common data-structures

TheoriesAndDataStructures

Showing how some simple mathematical theories naturally give rise to some common data-structures.

Attempting to answer the following questions:

• Why do lists pop-up more frequently to the average programmer than, say, their duals: bags?

• More simply, why do unit and empty types occur so naturally? What about enumerations/sums and records/products?

• Why is it that dependent sums and products do not pop-up expicitly to the average programmer? They arise naturally all the time as tuples and as classes.

• How do we get the usual toolbox of functions and helpful combinators for a particular data type? Are they ``built into'' the type?

• Is it that the average programmer works in the category of classical Sets, with functions and propositional equality? Does this result in some ``free constructions'' not easily made computable since mathematicians usually work in the category of Setoids but tend to quotient to arrive in `Sets` —where quotienting is not computably feasible, in `Sets` at-least; and why is that?

And lots of other stuff.

theoriesanddatastructures's Issues

Fix formatting

Make sure the paper (like the one in the .tex) file:

• uses the right format
• is fully anonymized
• uses the right fonts

Theories first

I believe (but am quite willing to discuss this) that we should take theories as primary, and structure the paper around theories and their names.

What we should not do then, is structure things around our interpretation of the data-structure underlying the 'free theories' (and their names). Yes, we do need to provide that interpretation, it is a useful result. But the exposition of the ideas need to have an order. And I believe that

• Theory --> Free Theory --> Interpretation of underlying data-structure

is the right order in which to expose the ideas.

Remove all editorial commentary

Already in the abstract we have a phrase like "With a bit of elementary mathematics," which is completely unhelpful. Adjoints from category theory, and much else besides, does show up here, and these are not 'elementary mathematics'. It doesn't matter if you believe that, the point is to communicate with our audience, who do not agree with that opinion.

The removal of Data.Nat.Properties.Simple in v1.0 of the standard library

Hi, this is a ping that the module Data.Nat.Properties.Simple will be removed in the upcoming release of v1.0 the standard library. The module has been deprecated since v0.14.

If you wish to continue using the latest version of the standard library you will need to update the following files:

Helpers/LeqLemmas.agda
Helpers/FinNatLemmas.agda
Helpers/FinEquivPlusTimes.agda
Structures/Experiments/Sidequest/Permutations/PermutationSequences.lagda
Structures/Experiments/Sidequest/Permutations/Vector.lagda
Structures/Experiments/VectorLemmas.agda
Structures/Experiments/Sidequest.lagda
Structures/Experiments/Sidequest/Permutations/SME.lagda

This can be done by replacing open import Data.Nat.Properties.Simple with open import Data.Nat.Properties.

[Most important issue] The Story.

To have a good paper, either one must have a very compelling result (which usually means solving a problem that someone else posed and whose solution is regarded as important and non-trivial by the community), or be able to tell a 'story' that motivates why the paper is worth reading.

After much work, I came up with

We give a rational reconstruction of some common (and
not-so-common) data-structures that arise in functional
programming. Our categorical approach also leads us to defining
standard functions which ought to be in all reasonable libraries of
data-structures. Being systematic in the exploration of the design
space reveals quite a lot of structure and information about
data-structures and their origins.

as a solid approach to our story. In fact, I then spent quite a bit of time crafting a few paragraphs (see the contents of TandDS.tex) laying out that story for our audience.

And then I read something entirely different in POPL19.org. It talks about Abstract Syntax Trees, serialization, remote execution, compositionality schemes, dynamical systems -- all neat stuff, but also all over the map, with no coherent thread. It has neat "slogans" that are correct -- but belong to a different story altogether.

Then the write-up falls prey to a simple diseases: what-I-learned-last disease. Just because one's most recent 'discovery' is at the top of ones' mind, and seems really cool [especially when it is], does not automatically make it the best thing to start the story with! (I see you, dynamical systems). One needs to carefully think about the audience, and lead them along from knowledge they likely already know towards new knowledge. Papers like T&DS need to be very pedagogical.

Upshot: Either we,

1. Go with the story I started in TandDS.tex, or
2. You propose a different story to @WolframKahl and I that you think is better.
   Then when all 3 of us agree on what story to tell, we all write that story, and stick to it.

Review & add citations to popl paper

Paper should not talk about theories/DS that do not yet exist

We should be very strict: in the paper, any theory / data-structure that does not have an accompanying full, complete implementation in Structures/ should not be mentioned anywhere except in 'future work'. That even includes Bag.