December 2005 - Haskell

RE: [Haskell] GADTs and GHC
by Simon Peyton-Jones 29 Dec '05

29 Dec '05

| My current uses of GADTs belong to the company I work for, so it would | be easier for me if *I* could check from time to time. Is the code | publicly available? Not yet, I'm afraid. But it will be soon. Simon

1 0

RE: [Haskell] Making Haskell more open
by Simon Peyton-Jones 29 Dec '05

29 Dec '05

Dear Haskell folk, A month or so ago I sent a message inviting suggestions about how to make Haskell more open, and in particular how to make it easier for Haskell users to contribute. There was quite a bit of traffic for a while, which has died down now. Here's a quick summary of what I learned. * Gour suggested using a Content Management System (e.g. Drupal http://drupal.org/) for haskell.org's front page. To me this sounds like a good plan. (e.g. "Drupal is software that allows an individual or a community of users to easily publish, manage and organize a great variety of content on a website." That sounds like what we are trying to do.) A CMS may offer more than we need, but it'd be more open and dynamic than the current setup. * There were suggestions of newsgroups and web forums. Different people seem to like different things. That's ok -- maybe a good content management system would support a lot of things, and people could choose. * Some people suggested using MediaWiki instead of MoinMoin for Hawiki. I have no idea about the issues here. Maybe it's just a matter of taste. * We don't have a plausible way of annotating GHC's user manual. One suggestion is a tree of Wiki pages, each linked from the corresponding section of the manual. We'd need an automated way to generate such a tree, and it's not clear what to do when moving from one release of GHC to the next. * #haskell has way more simultaneous logins than I realised. Good stuff! My sense is that the main action item is how to make haskell.org a better web site (This is with no disrespect to John and Olaf, who have done a great job. But I know they would be only too happy to share the load.) I'm no expert, but it sounds to me as if some content management system might well be just the thing. However, the thread didn't have many concrete offers of help. I'm hoping that is perhaps because you're all too shy to put yourselves forward! So: - is a CMS a plausible way forward? - which one? - is anyone, or small group, willing to set one up and look after it? Maybe not, in which case things are not at all terrible. But I thought it was worth asking. Simon PS: GHC is now using Trac as its bug tracker, and has its own Wiki as well. Please improve it! (Anyone can edit.) http://hackage.haskell.org/trac/ghc

11 16

Re: A question about fundeps <-> GADT interaction
by oleg＠pobox.com 28 Dec '05

28 Dec '05

[Sorry for possible duplication, our DNS server seems to be broken, and the sysadm is on vacation] I don't think that is the problem with GADTs. The following works > untype :: Term f a -> Term Untyped () > untype (Lit x) = Lit x > untype (Succ t) = Succ (untype t) > untype (IsZero t) = IsZero ((untype t)::Term Untyped ()) > untype (If c t e) = If ((untype c)::Term Untyped ()) > ((untype t)::Term Untyped ()) > ((untype e)::Term Untyped ()) Here's a more extensive example: > tlit :: Int->Term Typed Int > tlit = Lit > > [l0,l1,l2] = map tlit [0..] > > --ex2 :: Term Untyped () > ex2' = > If (IsZero (Succ (Lit 0))) > (untype l1) > (IsZero (untype l2)) ex2' of course won't typecheck if `untype' are removed.

3 7

Re: [Haskell] Announcing initial release of Shaskell
by David Mercer 28 Dec '05

28 Dec '05

On Tue, 27 Dec 2005 15:17:50 -0500, Dave Roundy wrote: >On Tue, Dec 27, 2005 at 01:36:53AM -0700, David Mercer wrote: >> We are pleased to announce Version 0.21a, the initial functioning >> release of Shaskell, our SHA2 library for (so far) ghc6. It supports >> sha256 and sha512 hashes in this version, and is "pure": no monads or >> C libraries are involved! > >You state in your abstract that the speed is comparable to a C >implementation. Do you have numbers comparing speed with the openssl >implementation, or any other implementations? > >David Roundy Doh! I meant to tone down that sentence, and insert the word "hopefully", as I haven't done speed testing in any depth yet, but a trip to the hospital this month left a few loose ends dangling, that being one of them! New abstract with toned down claim inserted to be in the future tense! Thanks for catching that. Performance of the sha512 implementation on 32 bit machines is currently pretty horrid, as would be expected, but the sha256 is much better. Speaking of testing, is anyone aware of any good test harnesses for benchmark comparison testing, it's been quite a while since I cared about such things and am out of touch with that corner of computing! Testing other sha2 libraries for comparison is going to be a bit of a bear, as most of them don't seem to have convenient command line versions/wrappers available, and I loath touching C, except with the traditional "make; make install" ritual of package installation. Thanks, -David Mercer Tucson, AZ

2 1

ANN: HDBC collection 0.99.0
by John Goerzen 28 Dec '05

28 Dec '05

I'm pleased to announce version 0.99.0 of HDBC, HDCB-postgresql, and HDBC-sqlite3. Tar.gz downloads are available at htp://quux.org/devel/hdbc. Darcs repositories are available under http://darcs.complete.org/. I have uploaded these three packages to Debian (sid). This release is intended as a beta release before 1.0. Changes since 0.6.0: * Make run and execute return more useful information * Added quickQuery * Added getColumnNames * Added fetchRowsMap, fetchRowsAL, etc. They return a map from column name to value. * Fixes for Hugs compatibility * Added getTables * Sqlite3 driver now supports useful return values from run/execute * Many new test cases -- John

1 0

GADTs and GHC
by Simon Peyton-Jones 27 Dec '05

27 Dec '05

Dear Haskell folk One of the interesting things about ICFP was the number of times GADTs came up, either in papers or in discussions in the breaks. Francois's invited talk was very inspiring, and that was just the beginning. Stephanie and Dimitrios and I are now busy revising our wobbly-types GADT paper (which is implemented in GHC, but never published http://research.microsoft.com/%7Esimonpj/papers/gadt/index.htm) We have a *far* simpler story now... but that means it'll reject some programs that would be accepted by the earlier version. We don't think this loss of expressiveness is important, but we'd like to check. Hence this message: If you use GADTs, would you to send us your GADT code, so we can check that we can still compile it? (A secondary reason for asking is that it'd be interesting just to see the way you are using GADTs.) If you send your code just to me, I'll collect it. You could a) send a complete Haskell program, which should compile and run b) send a Haskell module, or collection of modules, which should compile, but which isn't a complete program c) send a Haskell module using GADTs, but lacking the support modules that would enable it to compile d) send Omega code, which GHC won't understand, but which demonstrates some cunning use of GADTs All of these would be useful, even (c) and (d) --- we can eyeball the code. As a bonus, in the case of (a) or (b) I'll add your code to GHC's regression suite, so that all future releases will guarantee to run your code. [Or at least if not it'll be deliberate!] Tell me if you'd like this; it'll become visible in GHC's CVS repository. Thanks Simon

2 1

Announcing initial release of Shaskell, version 0.21a (sha256/sha512 library)
by David Mercer 27 Dec '05

27 Dec '05

We are pleased to announce Version 0.21a, the initial functioning release of Shaskell, our SHA2 library for (so far) ghc6. It supports sha256 and sha512 hashes in this version, and is "pure": no monads or C libraries are involved! Source and Ubuntu 5.04 binaries are at: http://davidmercer.nfshost.com/projects/shaskell/ (Shaskell-0.21a.hs is the current release). Project homepage is at: http://davidmercer.nfshost.com/projects/shaskell/shaskell.html Future releases will additionally support sha224, sha384, be Cabal-ized, and supply wrappers for hashing files and other data sources where the message length is not known in advance. Special thanks to Dominic Steinitz for invaluable suggestions. Any testing or feedback is of course welcome and appreciated! It is released under the (BSD compatible) MIT X license. Happy New Year, hopefully this will help improve the security of future crypto systems written in Haskell. Cheers, -David Mercer Tucson, AZ

2 1

ANN: MissingH 0.13.0
by John Goerzen 26 Dec '05

26 Dec '05

I am pleased to announce the release of MissingH 0.13.0. To download MissingH or view API docs, please visit: http://quux.org/devel/missingh or gopher://quux.org/1/devel/missingh To follow MissingH development with Darcs, please run: darcs get --partial http://darcs.complete.org/missingh 0.13.0 packages have been uploaded to Debian and should appear in sid within a few days. Changes in 0.13.0 since 0.12.3: * This release introduces some API changes that will affect a small percentage of programmers that use ConfigParser. * This release requires GHC 6.4.x or Hugs 2005xx or above. This has been noted in INSTALL. * MissingH.List: Committed some patches from Bulat Ziganshin to improve performance. * New function MissingH.List.subIndex based on suggestion from Bulat Ziganshin. Also added tests for it. * New module MissingH.Map, similar to MissingH.FiniteMap but for Data.Map instead of Data.FiniteMap. Also added tests for MissingH.Map. * New module MissingH.AnyDBM.MapDBM, plus tests for it. Converted from MissingH.AnyDBM.FiniteMapDBM. * Converted these modules to use MVars instead of IORefs: + MissingH.Logging.Logger * Converted these modules to use Data.Map instead of Data.FiniteMap: + MissingH.Logging.Logger + MissingH.MIMETypes + MissingH.ConfigParser (exposes an API change to a few people) * Converted these modules to use Text.Printf instead of MissingH.Printf: + MissingH.IO.HVFS.Utils + MissingH.Network.FTP.Server * Added deprecation warnings to these modules: + MissingH.FiniteMap (deprecation of Data.FiniteMap) + MissingH.AnyDBM.FiniteMapDBM (deprecation of Data.FiniteMap) + MissingH.Printf (introduction of Text.Printf) * Added deprecation warnings for two specific functions in MissingH.Str: subRe and splitRe. I had submitted the code for these to fptools, and the current releases of GHC and Hugs have Text.Regex.subRegex and splitRegex using the code for MissingH. Therefore, these functions in MissingH are deprecated in favor of the implementations in the standard library. * Added locking to StringDBM for thread safety improvements * Merry Christmas! Changes in 0.12.3 since 0.12.2: * Make StreamHandler now lock by default. (requested by Conjure people)

1 0

RE: [Haskell] Boxing (Day) Question
by Nick Benton 26 Dec '05

26 Dec '05

>That reminds me of something that I have wondered about for some >time. Why is there such reluctance to instantiate polymorhic functions >with the types with which they are used? (This isn't done automatically >in complilers right?) MLj, SML.NET and MLton all compile polymorphism this way. They can do it fairly straightforwardly because (a) they have the whole program available, and (b) because SML, unlike Haskell, doesn't have polymorphic recursion. Of course, you don't actually want a copy per source language instantiation type, just a copy per target language representation. The .NET CLR also compiles parametric polymorphism by representation specialization. Thanks to JIT compilation, it can do this lazily, at "run" time, sidestepping both the restrictions above. The details are non-trivial in this context (interfaces, runtime "types", etc.) - see the papers on generics by Andrew Kennedy and Don Syme for the hairy truth. Specialization is (generally) a big performance win over uniform representations for non-symbolic code (e.g. scientific code operating on floats). Nick

1 0

Boxing (Day) Question
by Ashley Yakeley 26 Dec '05

26 Dec '05

As I understand it, with unboxing switched on (->) actually has this kind: (->) :: ? -> ? -> * Reading the Core specification, GHC has a particular kind of "polykindism" which introduces kind "?", and defines specialisation such that "?" may be replaced by "*" or "#" inside any kind. Accordingly, (->) may be specialised: (->) :: * -> * -> * (->) :: # -> * -> * (->) :: * -> # -> * (->) :: # -> # -> * Examples: module Boxing where import GHC.Exts fooSS :: (->) Int Int fooSS 3 = 5 fooSS _ = 2 fooHS :: (->) Int# Int fooHS 3# = 5 fooHS _ = 2 fooSH :: (->) Int Int# fooSH 3 = 5# fooSH _ = 2# fooHH :: (->) Int# Int# fooHH 3# = 5# fooHH _ = 2# type Fun = (->) fooHH' :: Fun Int# Int# fooHH' 3# = 5# fooHH' _ = 2# Do any other type constructors or symbols have a kind with "?" in it? I like the "kind" approach to unboxed types. It automatically rules out "[Int#]" by kind mismatch, for instance. But I was disappointed I couldn't do this with GHC 6.4.1: data MyC s = MkMyC (s Int# Int) or class C s where c :: s Int# Int (in either case: "Kind error: Expecting kind `k_a19o', but `Int#' has kind `#' In the class declaration for `C'") There's no kind mismatch here, merely a restriction that the kinds of arguments to classes be #-free. I can't do this, either: newtype MyD (u :: #) = MkMyD (u -> Bool) GHC actually complains about parsing the kind signature. Would Bad Things Happen if this restriction were lifted? I don't have a pressing need for it actually, though this might be useful: class Boxed (b :: *) (u :: #) | b -> u, u -> b where box :: u -> b unbox :: b -> u In case you're worried, lifting the restriction would NOT allow uncompilable things such as newtype MyE (u :: #) = MkMyE u ...simply because there's already a straightforward restriction that values in type constructors have types of kind "*". It is merely the notion of "#-freeness" that seems unnecessary. It would, however, allow this: newtype Box (u :: #) = MkBox (() -> u) ...and quite possibly this: newtype Value (x :: ?) = MkValue (() -> x) I believe these can be compiled safely? -- Ashley Yakeley, Seattle WA

7 14