[Epigram-discuss] This Week's Patches in Epigram

Hi folks, This is definitely some sort of experiment, so I'm open to comments and suggestions (I always am, anyway). Every week, to keep up with Epigram, I do a code review on my own, starring at the previous week's patches, trying to make sense of them, and keeping track of the history. As Conor puts it, "stupidity, unlike lightning, loves to strike the same place twice". So I thought I would share these notes. I'm hoping that: * by distilling bits of knowledge every weeks, external readers could become more familiar with the system, potentially joining the debates ; * by questioning the commiters and developers, some discussion could be started, giving more precision about issues and solutions that what I can give in my limited space and time ; and * by seeing me suffering every week to understand your code, you will write detailed commit messages[1], literate code, describe deep changes on the blog or here, and pay me a Laphroaig every now and then. I have hesitated between sending this here or putting it on Epilogue. Your input is welcome, as usual. I find easier to answer to particular point by mail (by hitting Reply, and quoting only the necessary context). I know, I'm a bit old-fashioned. Also, I can't be bothered (well, I could if you insist) by Wordpress syntax when all I want is ASCII and fixed-sized fonts... [1]: Put "record prompt-long-comment" in your ".darcs/defaults" if it is not already prompting you. Anyway, here it goes for last week (Monday 24, Sunday 30): * "Constructor tag distill rules for IDesc", Peter Add distiller and elaborator support for tags in IDesc. Instead of having to write: con [ 'suc , [ n , []]] Or, equivalently with our Lisp convention: con [ 'suc n ] The user can simply write (thanks to elaborator support): suc n Conversely, when printing an element of a data-type (in an IMu), the distiller will turn: con [ 'suc , [ n , []]] Into the nicer: suc n * "BugFix: BugNameOrder.pig test now passes - Issue 11", Peter Christening (turning absolute names to relative names) used to give a partly reversed answer. For example, on this test case: module M ; module N ; module P ; make Q : Set ; root ; elab M.N.P.Q ; Elab would give: M.Q.P.N Whereas the expected answer is: M.N.P.Q This patch fixes that apparently, but I've no clue why/how. This file (ProofState/NameResolution.lhs) is a complete mystery to me. * "So.pig: updated to new IDesc", Adam Adam updated the implementation of the So data-type: So : Bool -> Set ---------------- oh : So True As a bonus, he tells you that if you have a "So False", you must be kidding: make no : So 'false -> :- FF ; * "PropSimp: simplify programming problems of type unit", Adam PropSimp, the propositional simplifier -- this doesn't mean that it only works in Prop: think of it as Epigram's Clippy, discretely discharging proofs and programming problems for you -- was already able to answer for you goals like: |- ? : Unit In this patch, Adam added support for the following, trivial programming problems: |- ? : < f ts : Unit > (the answer is "return Void") |- ? : < f ts : Prf Trivial > (the answer is "return Void"; Trivial is overloaded as a Unit) This leaves me wondering: couldn't we get simplification of such programming problems by the technology we already have for non-labelled goals, to avoid duplication such as Unit and < ... : Unit> above? * "IDesc: tweak pretty-printing and labelling for IMu", Adam As far as I can understand the code before change, it looks like labeling of IMu -- putting a readable name on fixed-points, for the user to recognize her data-type by its name instead of its signature functor -- was a bit over-optimistic, putting a label even when there was no description behind, hence(?) no name. It looks like there is still some \question about the correctness of the thing. * "IDesc: tweak pretty-printing and labelling for IMu" "Pretty-print types in "show hyps" at correct size" "IDesc: pretty-print IMu at AppSize", Adam These patches change the "size" we give to some bits and pieces so that, when pretty-printed, less parentheses are used. * "BUGFIX - Issue 10: only allow list syntax for enumeration ...", Adam In the past, we used to allow you to write: [] of type Nat, which would elaborate to: con [ 0, []] And similarly, [s t] would elaborate to, well, something dubious in general: con [ 1, [s, [ t, []]]] So, Adam has rightfully restricted these abbreviations to the elements of Enum (for which this syntax is the right one and we get the expected behaviour). With ./test/BugDescLoop.pig, he shows that, worse, this can go an infinite loop. I don't see how that did happen, Adam? * "Optimise coe and coeh by checking a sound (?) ..." "Rules: refactor and rearrange aspects", Adam This is the beginning of a long battle against proof terms exploding in our hands during coercion. To make things worse, coercion being an operator, it does not own a name supply. So, doing "stuffs" with values (higher-order representation) without a name-supply to quote them: tough business! In the first episode, Adam introduces an hopefully sound but surely not complete notion of equality, aiming at squashing the coercion quickly by noticing the definitional equality of the departure and destination types (hence, the proof in coerce would be refl, we don't need to go further). In the second episode, we discovered that bquote-ing from always the same (empty) name supply wasn't really sound. So, we removed the bquote and looked for a better solution. Stay tuned, there is some patches being written on this topic right now. * "Cochon: add "validate" tactic to manually ...", Adam You feel paranoid? You think Cochon is lying to you, accepting things that surely cannot type-check? Run "validate" on the suspicious entry and get the assurance that not only Cochon is broken but also the type-checker. This world is a lie. * "Compiler: refactor, correct Epic syntax ...", Adam The "Compiler/" directory got the visit of Adam, who tidied it up with a bit of documentation, a bit of refactoring, a bit of this, and a bit of that. At the same time, Compiler/OpDef.lhs joined the Epitome, welcome friend. This patch is worth a deeper study. Was there some new functionality introduced? Also, he transformed the "compile" command in Cochon -- which used to compile the proof-state to a binary thanks to Epic -- into an "execute" command, calling "System.system" with whatever string you want. A consequence is that you can use now Cochon as a terminal! I suspect the point was to be able to execute the binary generated by Epic, but I cannot see where Epic is involved. Any idea? * "Rules: refactor and rearrange aspects", Adam The "Axioms" and "Primitives" aspects have merged into a single "Primitives" aspect. The "AxCode" aspect -- code of the axioms -- and "QuotientDefinition" -- definition of the quotient equivalence relation(?) -- are merged into the "RulesCode" aspect. * "Levitated IDesc" "Eek, RulesCode aspect merge", Peter "IDesc: divide up CanPats/CanDisplayPats correctly ...", Adam Yes, you saw the magic words. IDesc have finally joined his old friend Desc in the air. This also means yet another definition of IDesc. So, you should really look at the patch instead of starring at my useless prose. I cannot describe the beauty I'm seeing. Oooooooh... * "Cochon: cope with prompt errors", Adam If you did something silly at the prompt, we won't blame you with a pattern-match failure anymore. Instead you'll get a J2EE-compliant stack of errors. You're forbidden to close your eyes when that happens. * "DisplayLang/DisplayTm: review (checkpoint)" "s/InDTm/DInTm/g and s/ExDTm/DExTm/g globally" "DisplayLang/DisplayTm: review (checkpoint 2)" "DisplayLang: Extract Scheme from DisplayTm. Document." "Move DisplayLang/Naming to ProofState/NameResolution. ..." "DisplayLang/Distiller: document (checkpoint)" "Move Distiller from DisplayLang to Distillation" "Remove useless imports" "'Type cast' is so C99. Let's try 'type annotation' ..." "Distillation: Extract Scheme and Moonshine ..." "Distillation/Scheme: document" "Distillation/Distiller: document" "ProofState/Developments: review (checkpoint)" "Epitome: put DisplayLang after Evidences. Experimental." "ProofState/ProofContext, Developments: (try to) document.", Pierre I worked a bit on documenting DisplayLang/*, Distiller/* and started ProofState/* (before giving up...). As for non-documentation stuffs, they have been documented in [https://lists.cis.strath.ac.uk/pipermail/epigram-discuss/2010-May/000012.html]. * "ProofState/Developments,ProofState: Girl, GirlMother: ...", Pierre A Girl (and, by extension, a GirlMother, its derivative) used to carry both a kind and maybe a scheme. A kind would tell you that a Girl is a definition (there was only one kind, really) while a scheme would, maybe, inform you that this girl corresponds to a programming problem. I decided that being a programming problem was a kind in itself, so there is no more Maybe scheme: a Girl is either a definition (Letg), or a programming problem coming with a scheme (Prog sch). Pushing this further, some functions in ProofState/NameResolution should probably be changed to exchange GirlKind instead of Maybe Scheme. Thanks for your attention, Regards, -- Pierre