From maeder at tzi.de Thu Jul 13 16:04:32 2006 From: maeder at tzi.de (Christian Maeder) Date: Thu, 13 Jul 2006 16:04:32 +0200 Subject: [Hets-devel] new pretty printing Message-ID: <44B652F0.2020402@tzi.de> Hi, meanwhile and thanks to Jian Chun, the hets sources have been completely ported to use the new pretty printing facilities given in Common.Doc and Common.DocUtils. The main advantage over the old version is that writing a single "Pretty" instance is now enough to produce plain text and latex (and possibly html or OmDoc one day). This avoids a lot of duplicate code but also has the small disadvantage that the instances have to be written with LaTeX in mind (i.e. for symbols or if keywords should be bold). Furthermore the handling of display and precedence annotations is no longer part of the user code but ready implemented by special functions to print identifiers, annotations and applications (within terms or formulas). idDoc :: Id -> Doc annoDoc :: Annotation -> Doc idApplDoc :: Id -> [Doc] -> Doc The new class looks as follows: class Pretty a where pretty :: a -> Doc Global annotations are no longer an input argument for every print function, but can be attached (at last) by: useGlobalAnnos :: GlobalAnnos -> Doc -> Doc The means to compose/align documents have been restricted. The former functions hang, nest, $$ and isEmpty (from Common.Lib.PrettyPrint) are no longer available. (For vertical composition $+$ instead of $$ can be used.) For diagnostic messages the name showPretty has been changed to showDoc. The consecutive use of <> or <+> for horizontal composition should be used with care, since too long lines without line breaks can result. (Better for printing several separate parts is to use "fsep".) showDoc :: Pretty a => a -> ShowS showDoc = shows . pretty More comments can be found in the source for Common.Doc. The LaTeX output for the basic libraries can be inspected at: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/src-distribution/daily/HetCATS/docs/Basic-Libraries.pdf (if the nightly build was successful only.) Suggestions or comments are welcome (as I'm not a LaTeX guru) Christian From maeder at tzi.de Thu Jul 20 10:56:39 2006 From: maeder at tzi.de (Christian Maeder) Date: Thu, 20 Jul 2006 10:56:39 +0200 Subject: [Hets-devel] Fehler Meldung In-Reply-To: <20060719223846.04dja2bqmss8owk4@webmail.informatik.uni-bremen.de> References: <20060719223846.04dja2bqmss8owk4@webmail.informatik.uni-bremen.de> Message-ID: <44BF4547.5030805@tzi.de> wjch868 at informatik.uni-bremen.de schrieb: > ein Fehler: > CoCASL/ATC_CoCASL.der.hs:257:23: Not in scope: data constructor `CoCASL_SL' > > CoCASL/ATC_CoCASL.der.hs:266:27: Not in scope: data constructor `CoCASL_SL' I've restructured the sublogics bits. Make sure that you get a clean cvs update. (cvs up -dPA) The toplevel Makefile has changed (CoCASL/Sublogics.hs is no longer needed for CoCASL/ATC_CoCASL.der.hs) Maybe delete the generated files CoCASL/ATC_CoCASL.der.hs and CoCASL/ATC_CoCASL.hs (the latter is protected, though) HTH Christian From maeder at tzi.de Mon Jul 31 14:23:54 2006 From: maeder at tzi.de (Christian Maeder) Date: Mon, 31 Jul 2006 14:23:54 +0200 Subject: [Hets-devel] new developers Message-ID: <44CDF65A.50907@tzi.de> Dear Developers, I hope to reach mainly all new developers like the interns from the IUB. Seeing more and more code producing annoying warnings I want you to stick to our programming guide lines. a) Produce code that does not emit warnings (we ignore warnings of library code since it is not our code and may be part of cabal packages in the future.) b) Source lines should be no longer than 80 characters! (Source files should not use tabs but have a final newline.) c) do not comment out code permanently, write proper comments instead d) use "make doc" to check if haddock understands your documentation Cheers Christian http://haskell.org/haskellwiki/Programming_guidelines