May 2005 - Haskell - Haskell.org

Re: Haddock Problem
by Dominic Steinitz 16 May '05

16 May '05

> > >On Sun, 2005-05-15 at 18:51 +0100, Dominic Steinitz wrote: >>/ > Dominic Steinitz writes: >/>/ > >/>/ I've downloaded >/>/ http://www.haskell.org/ghc/docs/latest/html/libraries/base/base.haddock and I >/>/ still get the same errors. Is this incompatible with Haddock version 0.6? >/ >Probably so because the current ghc library documentation is generated >with Haddock 0.7 (which is the current cvs version of Haddock). We're >hoping it will be released officially in the not to distant future >(though if you like you can use the cvs version now as it's perfectly >usable). > >The .haddock files are in a binary format and so are almost certainly >not compatible between versions (like ghc .hi files). > >It would be nice if haddock gave some sort of error message in this case >rather than ignoring the file. > >Duncan > > I think that's the answer. I just tried it on my windows machine and I got the following: C:\Documents and Settings\Dom\Codec>haddock -v -h -o docs -i http://haskell.org/ ghc/docs/latest/html/libraries/base,c:\ghc\ghc-6.4\doc\html\libraries\base\base. haddock haddock: Warning: The interface file "c:\\ghc\\ghc-6.4\\doc\\html\\libraries\\ba se\\base.haddock" could not be read. Maybe it's from a later version of Haddock? C:\Documents and Settings\Dom\Codec>haddock -v C:\Documents and Settings\Dom\Codec>haddock -V Haddock version 0.6, (c) Simon Marlow 2003 Why does the windows version give a warning when the linux one doesn't when they both appear to be the same version? And more importantly, can we have a version of haddock that is compatible with the latest release of ghc? I've tried building from source but run into problems. I'll post these separately if I have time. Yours, frustrated of Kingston.

1 1

Announce: Haskell Server Pages 0.2
by Niklas Broberg 16 May '05

16 May '05

== Haskell Server Pages == Release early, release often. I know, I know, but better late than never, so here it is: Haskell Server Pages (HSP), a Haskell-based language for writing dynamic web pages. Webpage and darcs repo available at http://www.cs.chalmers.se/~d00nibro/hsp Features: * Embedded XML syntax * A (low-to-mid-level) programming model for writing dynamic web pages * A runtime system, in the guise of a server utility, with support for: - session (through cookies) and application (through the server) state - interfacing to the HTTP request-response model - on-request compilation of pages (using hs-plugins) * A cgi-handler utility for use where the server can't be used (i.e. if you have no control over the resident web server). Supports everything the server does except application state and setting outgoing headers (plus it is atm considerably slower to respond). Things not working yet: * The server /only/ handles .hsp-pages (i.e. no images or the like), as it is intended to work as a plugin to general-purpose servers like Apache or HWS that should handle any other file types. To properly plug the HSP server in, I (or someone else so inclined) need to write bindings to such servers, currently the server utility only works in stand-alone mode. * No support for POST data yet. * Session handling needs improvement, currently session ids are generated from 1 up (I thought the hashUnique function had a more spread-out distribution...). * Probably a lot more things that I cannot remember right now. Things sorely missing: * Libraries, libraries, libraries and more libraries. * A "nice" model for continuations. Comments, critique, patches or whathaveyou most welcome. /Niklas

2 2

Re: Haddock Problem
by Dominic Steinitz 15 May '05

15 May '05

> Dominic Steinitz writes: > > > I've now used the -v option and it looks like haddock > > can't find the html files even though they are there :-( > > Anyone have any ideas? > > Maybe the interface description files are broken, > incomplete, or incompatible with your Haddock version? > > budweis:~/work/Codec$ mkdir docs > budweis:~/work/Codec$ url=http://haskell.org/ghc/docs/latest/html/libraries > budweis:~/work/Codec$ hdi=/usr/local/ghc-current/share/ghc-6.5/html/libraries > budweis:~/work/Codec$ haddock -v -h -o docs \ > -i ${url}/base,${hdi}/base/base.haddock Codec/Utils.hs > budweis:~/work/Codec$ > > No error here, and the external links worked too. > > Peter > I've downloaded http://www.haskell.org/ghc/docs/latest/html/libraries/base/base.haddock and I still get the same errors. Is this incompatible with Haddock version 0.6? [dom@tility Codec]$ haddock -V Haddock version 0.6, (c) Simon Marlow 2002 I don't think haddock gets as far as searching url=http://haskell.org/ghc/docs/latest/html/libraries because if I put url=http://gaskell.org/ghc/docs/latest/html/libraries I still get the same errors. On the other hand if I put hdi=/usr/local/ghc-current/share/ghc-6.5/html/mibraries then I get a different error message: Fail: does not exist Action: openFileEx Reason: No such file or directory File: /usr/share/doc/ghc-6.4/mibraries/base/base.haddock So it looks like haddock is finding base.haddock but for some reason ignores what is in it :-( Dominic.

2 1

Haddock Problem
by Dominic Steinitz 15 May '05

15 May '05

> On Sat, 2005-05-14 at 13:05 +0100, Dominic Steinitz wrote: > > Can someone point out what I am doing wrong? > > > > Thanks, Dominic. > > > > [dom at tility Codec]$ haddock Codec/Utils.hs > > --read-interface=http://www.haskell.org/ghc/docs/latest/html/base,/usr/share/doc/ghc-6.4/libraries/base/base.haddock > > > > Warning: Codec.Utils: the following names could not be resolved: > > Integral Word8 Int > > I don't believe that Haddock will download from a URL. > > Try downlading the base.haddock file first: > $ haddock Codec/Utils.hs --read-interface=base.haddock > > In this case it would be better if Haddock gave you an error about there > being no such (local) file as "http://www.haskell.org/g...", rather than > ignoring it. I'd call this a user interface bug. > > Duncan I still get the same problem: [dom@tility Codec]$ haddock Codec/Utils.hs --read-interface=base.haddock Warning: Codec.Utils: the following names could not be resolved: Integral Word8 Int Dominic.

2 2

Haddock Problem
by Dominic Steinitz 14 May '05

14 May '05

Can someone point out what I am doing wrong? Thanks, Dominic. [dom@tility Codec]$ haddock Codec/Utils.hs --read-interface=http://www.haskell.org/ghc/docs/latest/html/base,/usr/share/doc/ghc-6.4/libraries/base/base.haddock Warning: Codec.Utils: the following names could not be resolved: Integral Word8 Int

2 1

Using Haddock
by T.A.T.Davie 14 May '05

14 May '05

Hi, I've been trying to get haddock to work, and have successfully produced some html files using: haddock -h Module.hs -o docs However, the files seem to contain no useful information at all, even if I comment the modules as so: --| Its a fucking module module MyModule where {-| The 'square' function squares an integer. It takes one argument, of type 'Int'. -} square :: Int -> Int square x = x * x (the square example taken from the haddock documentation). And still I get no more documentation than: Contents Index MyModule Synopsis Produced by Haddock version 0.6 What on earth is it trying to do? Bob

2 1

ICALP'05: Call for Papers
by Luis Caires 13 May '05

13 May '05

___________________________________________________________________ CALL FOR PAPERS - ICALP'05 32nd International Colloquium on Automata, Languages and Programming July 11-15, 2005, Lisboa, Portugal http://icalp05.di.fct.unl.pt/ ___________________________________________________________________ The 32nd International Colloquium on Automata, Languages and Programming, the main conference and annual meeting of the European Association for Theoretical Computer Science EATCS will take place from the 11th to the 15th of July 2005 in Lisboa, Portugal. As a complement to the established Tracks on Algorithms, Automata, Complexity and Games (A), and on Logic, Semantics, and Theory of Programming (B), corresponding to the two main streams of the journal Theoretical Computer Science, ICALP'05 innovates on the structure of its traditional scientific program with the inauguration of a new special Track (C). The aim of Track C is to allow a deeper coverage of a particular topic, to be specifically selected for each year's edition of ICALP on the basis of its timeliness and relevance for the theoretical computer science community. Papers presenting original research on all aspects of theoretical computer science are sought. Typical but not exclusive topics of interest are: Track A (Algorithms, Automata, Complexity and Games): Giuseppe F. Italiano Università di Roma "Tor Vergata", Italy (PC Chair) * Algorithmic Aspects of Networks * Algorithms and Data Structures * Automata Theory and Formal Languages * Combinatorics in Computer Science * Computational Biology * Computational Complexity * Computational Geometry * Internet Algorithmics * Machine Learning * Parallel and Distributed Computing * Quantum Computing Track B (Logic, Semantics, and Theory of Programming): Catuscia Palamidessi INRIA Futurs and LIX, France (PC Chair) * Algebraic and Categorical Models * Databases, Semi-Structured Data and Finite Model Theory * Principles of Programming Languages * Logics, Formal Methods and Model Checking * Models of Concurrent, Distributed, and Mobile Systems * Models of Reactive, Hybrid and Stochastic Systems * Program Analysis and Transformation * Specification, Refinement and Verification * Type Systems and Typed Calculi Track C (Security and Cryptography Foundations): Moti Yung Columbia University, USA (PC Chair) * Cryptographic Notions, Mechanisms, Systems and Protocols * Cryptographic Proof Techniques, Lower bounds, Impossibilities * Foundations of Secure Systems and Architectures * Logic and Semantics of Security Protocols * Number Theory and Algebraic Algorithms in Cryptography * Pseudorandomness, Randomness, and Complexity Issues * Secure Data Structures, Storage, Databases and Content * Security Modeling: Combinatorics, Graphs, Games, Economics * Specifications, Verifications and Secure Programming * Theory of Privacy and Anonymity * Theory of Security in Networks and Distributed Computing * Quantum Cryptography and Information Theory SUBMISSIONS: ************ Authors are invited to submit an extended abstract of no more than 12 pages in LNCS style presenting original research on the theory of Computer Science. Submissions should indicate to which track (A, B, or C) the paper is submitted. No simultaneous submission to other publication outlets (either a conference or a journal) is allowed. The proceedings will be published in the Lecture Notes in Computer Science Series by Springer-Verlag. IMPORTANT DATES: **************** Workshop proposals due: November 28, 2004 Submissions: February 13, 2005 Notification: April 8, 2005 Final version due: April 30, 2005 PROGRAM COMMITTEE: ****************** Track A (Algorithms, Automata, Complexity and Games) * Lars Arge, Duke University, USA * Giorgio Ausiello, University of Rome "La Sapienza", Italy * Surender Baswana, Max-Planck-Institut fur Informatik, Saarbrucken, Germany * Hans Bodlaender, University of Utrecht, The Netherlands * Véronique Bruyère, University of Mons-Hainaut, Belgium * Adam Buchsbaum, AT&T Labs - Research, USA * Josep Diaz, Universitat Politecnica de Catalunya, Spain * David Eppstein, University of Irvine, USA * Andrew Goldberg, Microsoft, USA * Monika Henzinger, ETH Lausanne, Switzerland * Giuseppe F. Italiano, University of Rome "Tor Vergata", Italy (Chair) * Marios Mavronicolas, University of Cyprus, Cyprus * Peter Bro Miltersen, University of Aarhus, Denmark * Mike Paterson, University of Warwick, United Kingdom * Dominique Perrin, Université de Marne la Vallée, France * Seth Pettie, Max-Planck-Institut fur Informatik, Saarbrucken, Germany * Yuval Rabani, Technion, Israel * Antonio Restivo, University of Palermo, Italy * José Rolim, University of Geneva, Switzerland * Dorothea Wagner, University Karlsruhe, Germany * Tandy Warnow, University of Texas at Austin, USA * Christos Zaroliagis, CTI and University of Patras, Greece Track B (Logic, Semantics, and Theory of Programming) * Kenichi Asai, University of Ochanomizu, Japan * Joos Baeten, University of Eindhoven, NL * Peter Buneman, University of Edinburgh, UK * Zoltan Esik, University of Szeged, Hungary * Javier Esparza, University of Stuttgart, Germany * Marcelo Fiore, Christ's College and University of Cambridge, UK * Manuel Hermenegildo, Universidade de Madrid, Spain * Delia Kesner, Universite Paris VII, France * Kim Guldstrand Larsen, University of Aalborg , Denmark * Gopalan Nadathur, University of Minnesota, USA * Uwe Nestmann, EPFL, Switzerland * Catuscia Palamidessi, INRIA, France (Chair) * Amr Sabry, University of Indiana, USA * Davide Sangiorgi, Universita di Bologna, Italy * Roberto Segala, Universita di Verona, Italy * Harald Sondergaard, University of Melbourne, Australia Track C (Security and Cryptography Foundations) * David Basin, ETH Zurich, Switzerland * Christian Cachin, IBM Research, Switzerland * Alfredo De Santis, Universita di Salerno, Italy * Cynthia Dwork, Microsoft Research, USA * Matt Franklin, U.C. Davis, USA * Michael Goodrich, U.C. Irvine, USA * Andrew D. Gordon, Microsoft Research, UK * Roberto Gorrieri, Universita di Bologna, Italy * Yuval Ishai, Technion, Israel * Phil McKenzie, DoCoMo Labs., USA * Tatsuaki Okamoto, NTT Labs., Japan * David Pointcheval, ENS Paris, France * Tal Rabin, IBM Research, USA * Omer Reingold, IAS Princeton, USA * Adi Rosen, Technion, Israel * Amit Sahai, UCLA, USA * Andre Scedrov, University of Pennsylvania, USA * Igor Shparlinsky, Macquarie University, Australia * Nigel Smart, University of Bristol, UK * Moti Yung, Columbia University, USA (Chair) ORGANIZING COMMITTEE: ********************* Luis Monteiro Luis Caires Antonio Ravara Vasco Vasconcelos CONTACT ADDRESSES: ****************** For further information see: http://icalp05.di.fct.unl.pt/

1 2

Fixed-length vectors in Haskell
by oleg＠pobox.com 13 May '05

13 May '05

David Menendez wrote: ] data Vec n a where ] Nil :: Vec Zero a ] Cons :: a -> Vec n a -> Vec (Succ n) a ] data Vec_0 a = Nil ] data Vec_s v a = Cons a (v a) Ashley Yakeley wrote: ] vcons a v Zero = a ] vcons a v (Succ n) = v n S.M.Kahrs wrote: ] data Cons b a = a :. b a ] data NIL a = NIL There is a common pattern in all these approaches to fixed-length vectors: using *data* constructors to encode particular properties of the data structure. This approach goes back to Chris Okasaki (``From fast exponentiation to square matrices: An adventure in types.'' ICFP'99), who showed constructing not only of fixed-size vectors but also matrices that are guaranteed to be square. He also showed (quoting Ross Paterson, 1998) how to construct an AVL tree so that the AVL invariant is enforced by construction: http://www.haskell.org/pipermail/haskell/2003-April/011693.html This approach has the immense advantage that the invariant cannot be broken at all. One just can't have a list with fewer Cons cells than there are elements in the list. Chris Okasaki (in the above message) has also pointed out a drawback: all these data constructors take space to be present in memory, and take time to traverse. So, in all the above representations, to take the 1023d element of a 1024-element vector, we have to traverse 1023 Cons cells. The alternative is to encode the invariant -- the vector size, in our problem -- in *type* constructors, in phantom types. For example, > newtype PVector n a = PVector (Array Int a) The run-time representation of PVector n a is the same as Array Int a, which is quite efficient. There are no traces of the `Nat' can be found: we use the type-level invariant for type-checking only. So, we get additional assurances without distorting data structures and without any run-time penalty whatsoever. The drawback and the advantage of phantom types is that they are not ``bound'', so to speak, to a term -- they are just ``attached.'' If the user gets hold of the PVector constructor, the user can easily compromise our invariants. So, we have to hide PVector in a module and expose only functions that build the values of PVector one way or the other. We also have to make sure that these functions are correct -- because they constitute the trusted kernel of our invariant. The advantage of that approach is that we can implement very flexible invariants. Come to think of it, this approach isn't that far from LCF. David Menendez wrote: ] We would like a function "vec :: a -> Vec n a", such that "vec x" ] returns a vector of length n with every element equal to x. The basic ] algorithm is simple: ] ] vec{0} x = Nil ] vec{n+1} x = Cons x (vec{n} x) ] ] The usual way to declare a function like this involves a type class, ] which lets us define functions with different behaviors for different ] types: ] ] class Nat n where vec :: a -> Vec n a ] ] instance Nat Zero where vec x = Nil ] instance Nat n => Nat (Succ n) where vec x = Cons x (vec x) ] ] This gives vec the type "Nat n => a -> Vec n a", which is good because ] it points out that the type argument to Vec must be a natural, formed ] from Zero or Succ applied to another natural. ] ] However, this solution is unsatisfactory, because it requires the Nat ] class to include every possible function which might depend on a ] type-level argument. Actually it is not that difficult to create a Nat class with ``every possible function'' as a member: > class Nat' n e f where doit :: e a -> f n a > newtype VecFN n a = VecFN (Vec n a) > newtype ID a = ID a > unVecFN (VecFN x) = x > unID (ID x) = x > instance Nat' Zero ID VecFN where doit (ID a) = VecFN Nil > instance Nat' n ID VecFN => Nat' (Succ n) ID VecFN where > doit (ID a) = VecFN (Cons a (unVecFN $ doit (ID a))) > vec' :: Nat' n ID VecFN => a -> Vec n a > vec' = unVecFN . doit . ID *Vector_GADT> vec' 2 :: (Vec Three Int) [2,2,2] If we wish now to implement fromList function, we do > newtype FromList' n a = FromList' > { runFromList' :: Maybe (Vec n a) } > > fromList' :: Nat' n [] FromList' => [a] -> Maybe (Vec n a) > fromList' = runFromList' . doit > > instance Nat' Zero [] FromList' where doit = \l -> FromList' $ Just Nil > instance Nat' n [] FromList' => Nat' (Succ n) [] FromList' where > doit = \l -> case l of > x:xs -> FromList' (fmap (Cons x) (runFromList' $ doit xs)) > [] -> FromList' Nothing *Vector_GADT> fromList' [1,2,3] :: (Maybe (Vec Three Int)) Just [1,2,3] *Vector_GADT> fromList' [1,2] :: (Maybe (Vec Three Int)) Nothing This tagging and untagging may be a bit annoying. OTH, FromList', ID, etc. are all newtypes. Ashley Yakeley wrote: ] > impossible :: Empty -> a ] > impossible _ = undefined ] ] It's unfortunate that we can't define impossible without using bottom. I ] dislike using bottom, and here we have a function that cannot return ] bottom unless it is passed bottom. Such functions should be definable ] without using bottom, but this one isn't. Well, we can write: > impossible = impossible Or, better, > impossible = error "I'm afraid I can't do that, Dave"

2 1

wanted: "source_location_of" function
by Johannes Waldmann 13 May '05

13 May '05

Dear all, I have a Haskell program with a textual interface (Textareas in CGI, actually) where the user has to type/edit representations of Haskell data in several places (handled with Read/Show, for the moment). Now for each such input field, I want to add a link to the haddockumentation or source code of the corresponding data declaration, and preferrably without changing (much) of the program it is large, and the interface is generic: the actual textarea does not know anything about the type of its contents, other than being an instance of Read and Show. What would be a good way to obtain this information automatically? Probably I want a class with a method giving sth. like source_location_of ( _ :: Data.Map k v ) = [ "Data", "Map" ] where instances are derived automatically. Could be done with DrIFT perhaps ... (But I think I need the package name for the module as well.) Any ideas or pointers would be welcome. -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

1 0

ANNOUNCE: Haskell Communities & Activities Report (8th ed., May 2005)
by Andres Loeh 13 May '05

13 May '05

On behalf of the many, many contributors, I am pleased to announce that the Haskell Communities and Activities Report (8th edition, May 2005) http://www.haskell.org/communities/ is now available from the Haskell Communities home page in several formats: PDF, for screenreading as well as printing, HTML, for those of you who prefer not to deal with plugins or external viewers, and PostScript, for those of you who have nice quick printers that do not grok PDF. Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. I hope you will find it as interesting a read as we did. If you haven't encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and well in time for the actual deadline ;) ) to the call. The editor collects all the contributions into a single report and feeds that back to the community. When we try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: ---------------------------------------- End of October 2005: target deadline for contributions to the November 2005 edition of the HC&A Report ---------------------------------------- Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to `register' with the editor for a simple e-mail reminder in the middle of October (you could point us to them as well, and we can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! Andres Loeh <hcar at haskell.org> <andres at cs.uu.nl> -- Haskell Communities and Activities Report (http://haskell.org/communities)

1 0