Epilogue

Needed to do a bit of hacking at the weekend, so I just sorted out the naming mechanism to allow and generate the x^n notation. Try typechecking lam X : * => lam X : X => X and lam X : * => lam X : X => X^1.

Next mission, a very simple interactive editor for proof states, given by (Cursor (Key UId Reference)) for now, but we’ll go tree-structured later. In the first instance, this should just have holes and lets, with refinement and undo as the basic operations. This requires the ability to propagate an update. Before long, though, we’ll want to have parametrised things, and a hierarchical structure. We should be able to knock up a serviceable toy in fairly short order.

OK, I think I have a plan. I’m gonna

• hack in Bool and W directly, leaving ‘data’ alone for the moment
• add the relevant extra eliminators for equations (dom, cod, sym)
• make coe go into functions, pairs and trees
• add a constructor for extensionality

If that works out, it’s time to rethink data, then remove Bool and W. I’ll keep youse posted.

I’m following a plan to get us to stage 2 of the equality story: proof irrelevance. I’ll update this post as I go, but so far I’ve

• split Term into syntactic stuff (still Term) and semantic stuff (new file Value)
• lumped the contents of Equality into Value and removed Equality
• threaded a freshroot through eval and everything which calls it (no fun at all)
• added source and target to coe and coh
• made the computational behaviour of coe and coh compare source with target if the proof isn’t already refl
• made normal proofs of equations equal
• made spine comparison of coe just compare sources and targets, rather than (irrelevant) proofs
• did some very basic testing
• pushed the changes
• gone in search of a drink

I’m trying to keep Epitome sane as I go.

Meeting:

• Thorsten should type:
  1. darcs get http://sneezy.cs.nott.ac.uk/darcs/term
  2. cd term
  3. chmod +x Setup.hs
  4. ./Setup.hs configure --prefix=$HOME
  5. ./Setup.hs build
  6. ./Setup.hs install --user
  7. (and providing $HOME/bin is in your path:) epigram
• The next job in term is to build equality in these steps:
  1. Propositional equality
     
     coersions between equal types (and the proof that these are coherant)
     
     and the structural rule for application
     
  2. Proof-irrelevance for equality, to do this right we need to decide equality during evaluation (if we do not have a proof of an equation but it’s homogeneous, then we win anyway). The upshot is Equality.lhs and eval from Term.lhs need to be in the same file.
  3. Observational equavalence, at some point (sooner rather than later) we’ll include the structural rule for :
     

  Thorsten pointed out that is rule can be derived from substution of equals for equals plus the more primitive:
  
  Having this gives OTT a simpler core, but Conor prefers the first version because it is easier to program with.

I just had the following interaction with the version I just pushed:

*ParseEvalCheckRender> parseit synthit
input:
Nat => => data X : * where <z> : X ; <s> : all x : X => X
two => => <s <s <z>>> : Nat
plus => => lam m => lam n => m elim{Nat} (lam x => Nat)
% n
% (lam x => lam xh => <s xh>) :
% all m : Nat => all n : Nat => Nat
---
plus two two
STOP

<s <s <s <s <z>>>>>
data X : * where <z> : X ; <s> : all x : X => X


Some sort of progress, I think.

1. UI. Some interest from Nick Thomas. Joel is planning an experiment with gtk2hs.
2. Using darcs is working very well. Discussed structure our darcs repos.
3. Status of Epigram 2. We have been hacking the core recently. The afore mentioned ‘Up’ and ‘Down’ terms are in with the supporting parser, (not very) pretty printer,type checker equality checker. Peter has been implementing datatypes. Next is the equality type, and then on to wrapping it in a representation of holes.
4. Thorsten discussed injectivity of type constructors.
5. Move to the board to discuss 3 further. Specifically Conor proposes a short path to making something go. Two main areas: a) Finishing Core and moving on to theorem prover. b) Concrete syntax, comms protocol.

6. Division of work. Joel and Wouter to look at concrete syntax and comms. James and Peter to look at core and theorem proving.
7. The advantages of supporting observational type theory sooner rather than later will afford us simplifications in the implementation. (Thorsten to go into more detail about this on the blog).

I’ve just completed the upgrade of the blog software to Wordpress 2.0, fun. The shouldn’t be too much new stuff to get used to, the admin pages look different but are fairly similar in content.

You may notice that I’ve swapped darcs activity in for cvs, this time round it doesn’t use the hack of commenting on a dummy post and uses rss instead, try clicking on on of the patches to find out why.

If you find any bugs, leave a comment and I’ll fix.

Although it might seem all quiet on the Epigram front, in actual fact there is somewhat of a blitz going on at HQ and I thought I’d let you in on some of what has been going on.

As you can see in the last post Conor changed his mind slightly on what Terms where going to be, in those pictures, Up terms are those you can sythesize a type for (and are now called Synth), Down terms are terms you have to push the type into and check (and are now called Check).

Since changing to this representation would break a lot of what is already there we took our experiment ‘offline’ and Conor, James, Wouter and I set to work on implementing all the kit we needed for the new underlying terms (and values). When I say offline, I really mean we created ourselves a Darcs project as it seemed the perfect experiment of our plan to move wholesale to darcs. The results of the tinkering and the experiment can be grabbed by entering ‘darcs get http://sneezy.cs.nott.ac.uk/darcs/term’. It’s not finished, but a few days work bore many fruits.

Next up, holes and Datatypes.

More to say about this anon, but here are some boards, before I clean them to write some more.

Just a thought, which I decided to scribble down before I forgot it.

Key policy: Epigram is a declare-before-use language, temporally as well as spatially. When you say x, you get the most local existing x at that time, or you get a new x generated as locally as possible. In a declaration, spare names go into the generalisation prefix; in a rhs, spare names go into the where clause, one way or another. Naming is a surrogate for pointing, so once the bond of reference is created, it must not be broken by ill-propagated renamings, capturings, or whatever. It’s this policy which enables scope resolution at any point in time: there should never be any issue about the referent of an identifier.

Now, we go backwards as well as forwards, this time around, so what happens when you delete information. Well, there are at least two sorts of undo: devaluation (removing (parts of) the value of a symbol) and degeneration (removing the symbol altogether). Now, you propagate a devaluation by rechecking and devaluing everything which depends on a devalued symbol. Degeneration is much scarier. But I remember now, there’s a funny thing. If you set things up right, you don’t need degeneration, exactly…

Imagine we have only let (the sooner we turn data into sugar for let, the better). You can devalue a let, replacing the top rhs by a shed. Now, key editing move: you can commute one let past another by turning

let f blah ; let g waffle

into

let g waffle ; let f blah

if waffle does not depend on f, or

let g waffle where f blah ; let f blah

otherwise. Degeneration is thus the repetition of this refactoring until the global f falls off the end!

(For data as it is now, you need to generate a bunch of lets for the type, its constructors and its various gadgets.)

In terms of what happens to typedness, we should try to ensure that devaluation cannot increase the amount of brown. Intuitively, removing information cannot increase the amount of stuff which is definitely wrong. Of course, we should expect yellow all over the shop.

I mention this largely because this is pretty fundamental stuff, in terms of the propagation of updates around the system. It’s rooted in the proof engine, below the elaboration layer, so the time to figure it out is now.

Points from today’s meeting:

• darcs is being tested but we’ll hold off using it for epigram for a week or so.
• Still waiting for
• Epigram now has a independent type checker for terms and the parser is connected so that it can be tested out. Consumers of this service to follow. Thorsten questioned whether it was sensible to test it via the parser or whether we should generate terms using quickcheck to test it.
• Wouter has written some haskell to handle expanding includes in Epigram 1. This hasn’t been been hooked up yet
  as it requires some elisping.
• Whilst on the subject of elisp we considered whether it might be feasible to move to GNU Emacs for Epigram 1 as the carbon version for OS X is quite nice.

Turning into code at a whiteboard near you…well, near me, anyway…

There were a few concrete points that did come out of today’s meeting.

Wouter should write a few bits of Haskell to fix Thorsten’s problems using include.

We also need several mailing lists:

• Epigram general e-mail address - epigram-help at epig etc
• Epigram developers - epigram-dev at cs dot nott etc
• Epigram nottingham crew - epigram-notts at cs dot nott etc
• General epigram discussion - epigram at durham etc

All with suitable links on e-pig if it’s relevant.

Conor also showed that lambda abstracting neutral terms requires more work than you might think at first.

After hooking Conor’s dummy elaborator to the bits of my crummy editor, the result is the very first preview of Epigram 2 in action.

The editor doesn’t do much and the elaborator says everything type checks, but it’s a start.

Try:

> cvs update -d
> cd current/src/
> make
> echo 'lam X : * => X' > Lam.epi
> ./epigram Lam.epi


You should see a poorly pretty printed version of the original, with highlighted identifiers on a grey background. Try giving the following commands to the editor:

> down
> right
> left
> up

You should see the focus change as you navigate the abstract syntax tree.

To quit the editor, just type quit.

There’s not much else you can do at the moment. Next on the todo list are better pretty printing and actually being able to request elaboration after filling in a shed.

Last week we went through the brainshitting list we produced in Durham early this year to see where we are and where we should go. A bit delayed here is the commented list:

>> needs more equipment, & more think. (MRF)
Read the rest of this entry »

Hank dropped by. I scribbled this.

In a funny mood on Saturday, wrote this. Have several more important things to do, but as displacement activity goes, it could be worse. I recommend this kind of berserking: just typeset a program you happen to have handy, then explain what’s going on. Everyone should try it.

Meanwhile, comments welcome, especially WTFs from those with a more conventional perspective.

First instalment of an Epigram 1 change I’ve been intending to do for ages. Almost no effort required! I’ve fixed things so that variables named but not declared in the premises of a rule get inserted implicitly at the left end of the rule (as James McKinna used to argue) rather than as locally as possible (as Randy Pollack used to argue). vcons now gets X and n implicitly before x and xs; n used to come in the middle, unless you explicitly forced it leftward. Generally, I find that partial applications work more pleasantly more often with James’s convention. You can still force things rightward with an explicit premise (which doesn’t mean the arg has to be explicit).

Anyhow, I imagine this change may cause minor damage. I’ve tried a few examples, and I had to tweak a thing or two: mostly stuff that was a bit chancy anyway and should have been cleaned up long ago. I suggest that regulars try out their favourites and howl if they aren’t readily fixable.

There will be a second and more subtle change: at the moment, uninstantiated metavariables in rules are generalised to yield implicit arguments wherever they end up; these also should be shunted leftward where possible. Probably won’t do any damage, except to code which relies on the current morally random placement.

I don’t think we should generate new binaries just yet; I’ll try and get this cleaned up as soon as possible.

If we want darcs, we need to consider some issues and make sure everyone is happy to make some changes in the way they work on Epigram.

Firstly, why is it a good idea, without getting into CVS bashing?

1. It’s Haskell — thats good politically (we like functional programs), and, maybe even, practically (if it don’t work fix it!).
2. The theory of patches is an good idea. It gives us more control over different versions/experiments/dead ends. Say I had a copy of the main development trunk, but also an experimental version of my own devising, if Conor writes a bug fix on the main version I can (if appropriate) apply that patch to both my versions. If I do some work on a file that breaks the main trunk I need only send a patch to Conor who can propogate the changes through the rest of the system before we make both patches publicly available. I can think of many more such situations. Perhaps you can too.
3. OK I promised no CVS bashing but… wouldn’t it be nice to move files/folders and keep their history (there, I said it).

There is no halfway house here though, we can’t piggy back CVS on DARCS or vice versa… We either twist and get everyone up to speed on the new practices asap or we stick save the wandering around in the dark for a bit but, in my opinion, lose out in the long run.

So what about the practicalities, well anyone with darcs will be able to pull down a copy from the website, from then on we make these changes:

cvs commit
becomes
darcs record
(locally) or
darcs push
globally
cvs update
becomes
darcs pull

Theres a big list of cvs -> darcs translations here. The rest of that page is a good introduction to why DARCS is different, it’s worth a read.

So what about it?

Just to let yiz know, Andres has just sent me our current HCAR entry to update. I’ve put it under cvs here, so we can all tweak it as we see fit.