Add Queue datatype

[silas-hw]

Will eventually resolve #3083. Uses the two-list method mentioned in #3072 (but in a PR not generated by an LLM this time).

There may be some poor stylistic choices due to my unfamiliarity with the standard library, for which I am sorry! There are some 'low hanging' basic operations that could still be added, but I think those would be good for separate PRs.

[JacquesCarette]

When adding new functionality, we tend to make somewhat larger PRs than when fixing things. In particular, a bunch of properties should be proved too. The main reason is that quite often the proofs reveal when some of functionality was written in a correct-but-hard-to-use (or reason about) manner. So basically all of #3083 will need to be done in this PR.

On the other hand, asking for reviews of the intermediate steps is a good idea.

[JacquesCarette]

Probably consider fromSnocList too.

[jamesmckinna]

Some alternative suggestions as to implementation.

Against @JacquesCarette , and because I'm a bit more 'OO-minded', I tend to put things like Empty/isEmpty as manifest fields of the record, because then I don't have to think about the scope management. Similarly toList, because all the pieces are at-hand without further ado... but YMMV.

As for references for this kind of implementation, probably Okasaki's "Purely functional data structures" would be the go-to citation?

Oh, and: fix-whitespace!

[gallais]

As for references for this kind of implementation, probably Okasaki's "Purely functional data structures" would be the go-to citation?

There is also https://doi.org/10.1017/S0956796800001489

[jamesmckinna]

When adding new functionality, we tend to make somewhat larger PRs than when fixing things. In particular, a bunch of properties should be proved too. The main reason is that quite often the proofs reveal when some of functionality was written in a correct-but-hard-to-use (or reason about) manner. So basically all of #3083 will need to be done in this PR.

On the other hand, asking for reviews of the intermediate steps is a good idea.

So, eg.:

toList-fromList : toList (fromList xs) ≡ xs

The converse direction requires some simulation relation on Queues... but that's (probably) worth discussing/thinking about a bit more... although the toList observer of 'internal state' is already one kind of characteristic...

[jamesmckinna]

Similarly, should this be called null? or isEmpty? or what, in general...

[silas-hw]

Note: sorry for pushing a file with holes in!

[gallais]

Note that the equivalent properties in Data.Nat.Properties have more complex names:

m+n≡0⇒m≡0 : ∀ m {n} → m + n ≡ 0 → m ≡ 0
m+n≡0⇒n≡0 : ∀ m {n} → m + n ≡ 0 → n ≡ 0

I personally would expect ++-[] to be a proof that xs ++ [] ≡ xs

[silas-hw]

There are two hard things in computer science...

Descriptive names is definitely something I need to get a hold of!

[silas-hw]

Should instances bet put into a .Instances module, or put into the file that defines their component parts? Whichever we go with, I think it should be put into the style guide.

[JacquesCarette]

Should instances bet put into a .Instances module, or put into the file that defines their component parts? Whichever we go with, I think it should be put into the style guide.

Yes to instances going into a .Instances module. If the component parts are independently useful, they can go elsewhere. Fully agree that should go in the style guide.

[I'll do a full pass on all the comments / code later.]

[silas-hw]

Oh no! Some properties of IsQueue require an already existing instance of RawQueue to be provided Thus an instance of IsQueue would require properties proven that themselves require an instance of RawQueue - circular dependency! (Properties would import Instances, and Instances would import Properties)

[jamesmckinna]

hmmm... circular dependencies? Does splitting the Spec module into two help at all?

[silas-hw]

I think it would rather be splitting Instances. I.e. have TwoList-RawQueue defined as an instance somewhere, have that imported into Properties, which can then be imported into some module that defines TwoList-IsQueue - but this does go against the current style.

Or maybe moving the definitions used in the instance of IsQueue to the Instances file itself, but this would result in a Instances file containing mostly properties.

[jamesmckinna]

Ca the call to fromList> (reverse ys) be fused into something simpler?

[gallais]

In my mind it should be a chips (<>>).

However, that is because I personally would expect the type of back & front to be the
other way around. This is how I visualise a queue:

  ,--- head of the queue from which we are dequeueing values
  |                  ,---- split where the front ends and the back starts
  v                  v     
  1 :: 2 :: 3 :: []    [<] :< 4 :< 5 :< 6
                                        ^
                                        |
  very back of the queue where we enqueue values

Values travel up the queue from right to left until they reach the head and are popped.
The operation by which we turn the back into the new front when we notice the current front
is empty is back <>> [] because _<>>_ respects the left-to-right ordering of values.