- Haskell-Cafe - Haskell.org

retrospective on 'seq' -> 'unsafeSeq' ?
by Henning Thielemann 15 Apr '08

15 Apr '08

When reading the section "10.3 Controlling Evaluation Order" in "History of Haskell" I thought that the example that justified the 'seq' to be unrestricted polymorphic was mainly a debugging problem. I wondered if the better solution would have been to provide an 'unsafeSeq' which has no type restriction but must be absent from production code just like 'trace'. With 'unsafeSeq' one could nicely play around until time and space behaviour is as wanted and then one can replace all 'unsafeSeq's by 'seq' while adding type constraints accordingly. (Analogously there could be an unsafeShow that allows showing offending values in an 'error' without adding a Show constraint to the type signature.)

6 5

Monad proof
by Rafael C. de Almeida 15 Apr '08

15 Apr '08

Hello, I was studying Monads and I was trying to think about new Monads I could define. So, a question poped into my mind: how is proof regarding the 3 Monad laws handled? I know that, aside from testing all the possible values (and there can be a lot of them), there's no general way to prove it. Nonetheless, I think that it would be insightful to see how people write those proofs for their monads -- specially for new user monads. Is there some article or some notes on proving that Monads are implemented correctly? []'s Rafael

5 4

ANN: darcswatch, a way to track your contributions
by Joachim Breitner 14 Apr '08

14 Apr '08

Hi Haskellers, today I scrached an itch that was icking for a while: When I submit patches to some project or person, I’m never sure that I won’t forget checking that the patch will actually be applied. But if I forget, and the maitainer forgets (or decides against), my patch would be lost. Therefore I wrote a little haskell program darcswatch, which has a bunch of patches to track, and a bunch of repositories to watch, and shows you what patches have to be applied where. You see it in action here: http://darcswatch.nomeata.de/ To use it conveniently, I have put this in my ~/.darcs/defaults: send sign send cc darcswatch(a)nomeata.de so all patches I send will be signed and copied to that address. For security reasons, only mails signed by allowed gpg keys are accepted and the webpage is updated. It is also updated every hour by a cronjob. As you can see the program is ready to track patches by several authors. If you want to try it out and help debug it, just drop me a (signed) note with your gpg key-id, also listing all repositories you want to be tracked. I would also appreciate any help with programming darcswatch. There is a darcs repository on http://darcs.nomeata.de/darcswatch/ (with DarcsWeb at http://darcs.nomeata.de/cgi-bin/darcsweb.cgi?r=darcswatch;a=summary) There is a lot to do yet, I quote the TODO list on http://darcs.nomeata.de/darcswatch/README : * Support for tagged repositories (fetching older inventories) * Cache the inventories and only update when needed, by issuing a HEAD request. * Add a download link to each pach * Add the diff to each patch, with some javascript hiding/unhiding. * Cabalize the program. * Detect inverted patches and treat specially (e.g. an unapplied patch where the user also submitted an inverted patch can be considered obsolete) * Nicer output (CSS magic!) * (Maybe) Add repositores per gpg signed command Haskell projects could also make use of darcswatch by tracking patches that were submitted to a bugtracker (e.g. for xmonad) or via the mailing list, to make sure no contribution is lost. I could also imagine that it might be a service that, if proven reliable, could be run on community.haskell.org or similar. As always, comments are appreciated. Enjoy, Joachim -- Joachim "nomeata" Breitner mail: mail(a)joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata(a)joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata(a)debian.org

1 0

Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
by Adam Langley 14 Apr '08

14 Apr '08

On Sun, Apr 13, 2008 at 6:32 PM, Chris Smith <cdsmith(a)twu.net> wrote: > Does old code that handled these headers stop working, just because it > was looking in the "other" section, but now needs to check a field > dedicated to that header? Yes, but it would be very sad if we couldn't do common header parsing because of this. I'd suggest that all the headers given in RFC 2616 be parsed and nothing else. That leaves the question of how we would handle the addition of any extra ones in the future. Firstly, packages could depend on a given version of this interface and we declare that the set of handled headers doesn't change within a major version. Better would be some static assertion that the interface doesn't handle some set of headers. Maybe there's a type trick to do this, but I can't think of one, so we might have to settle for a non static: checkUnparsedHeaders :: [String] -> IO () Which can be put in 'main' (or equivalent) and can call error if there's a mismatch. AGL -- Adam Langley agl(a)imperialviolet.org http://www.imperialviolet.org

2 2

Re: [Haskell-cafe] Re: Embedding newlines into a string?
by Abhay Parvate 14 Apr '08

14 Apr '08

Yes, they are. That's what perhaps Neil Mitchell means by mapM_ putStrLn == putStr . unlines And whether the trailing newline is to be called the last blank line depends upon the convention; The string that is output in both the cases contains a single newline character. Are you calling that a blank line at end? And I actually meant to reply to haskell-cafe as well; omitted haskell-cafe by mistake. Anyway, you got the same answer from two people! This time I am including haskell-cafe in the recipients. Regards, Abhay On Mon, Apr 14, 2008 at 4:05 PM, Benjamin L. Russell <dekudekuplex(a)yahoo.com> wrote: > Abhay Parvate, > > Thank you; that answered my question. > > Then, the following two lines of code should be > equivalent: > > In hanoi.hs: > hanoi n = mapM_ putStrLn (hanoi_helper 'a' 'b' 'c' n) > > In hanoi_unlines.hs: > hanoi n = putStr (unlines(hanoi_helper 'a' 'b' 'c' n)) > > I tested them both out on WinHugs (Version Sep 2006); > they both generated one blank line at the end. > > Benjamin L. Russell > > --- Abhay Parvate <abhay.parvate(a)gmail.com> wrote: > > > unlines puts newline after each string; putStrLn > > puts newline after the > > given string. As a result, the output contains two > > newlines in the end. You > > can use putStr instead, since the resultant string > > from 'unlines' will have > > a newline at the end. > > > > On Mon, Apr 14, 2008 at 2:12 PM, Benjamin L. Russell > > <dekudekuplex(a)yahoo.com> > > wrote: > > > > > Ok; much better. Here's my new type signature and > > > definition: > > > > > > hanoi.hs: > > > hanoi :: Int -> IO () > > > hanoi n = mapM_ putStrLn (hanoi_helper 'a' 'b' 'c' > > n) > > > > > > hanoi_helper :: Char -> Char -> Char -> Int -> > > > [String] > > > hanoi_helper source using dest n > > > | n == 1 = ["Move " ++ show source ++ " to " ++ > > > show dest ++ "."] > > > | otherwise = hanoi_helper source dest using > > (n-1) > > > > > > ++ hanoi_helper source using dest > > 1 > > > ++ hanoi_helper using > > source > > > dest (n-1) > > > > > > Then in WinHugs (Version Sep 2006): > > > > > > Hugs> :load hanoi.hs > > > Main> hanoi 2 > > > Move 'a' to 'b'. > > > Move 'a' to 'c'. > > > Move 'b' to 'c'. > > > > > > Great! > > > > > > One minor question: I tried out both of your > > > following suggestions: > > > > > > > > mapM_ putStrLn (hanoi 2) -- outputs each > > move > > > > in a new line > > > > > putStrLn (unlines (hanoi 2)) -- same as > > > > previous line > > > > > > and discovered that putStrLn with unlines (the > > lower > > > option) in fact generates one extra blank line at > > the > > > end. Just curious as to why.... > > > > > > Benjamin L. Russell > > > > > > --- Tillmann Rendel <rendel(a)daimi.au.dk> wrote: > > > > > > > Benjamin L. Russell wrote: > > > > > but got stuck on outputting newlines as part > > of > > > > the string; > > > > > > > > quoting is done by the show function in Haskell, > > so > > > > you have to take > > > > care to avoid calling show. your code calls show > > at > > > > two positions: > > > > (1) when you insert the newline into the string > > > > (2) when you output the string > > > > > > > > with respect to (1): > > > > > > > > you use (show '\n') to create a newline-only > > string, > > > > which produces a > > > > machine-readable (!) textual representation of > > '\n'. > > > > try the difference > > > > between > > > > > > > > > '\n' > > > > > > > > and > > > > > > > > > show '\n' > > > > > > > > to see what I mean. instead of using (show > > '\n'), > > > > you should simply use > > > > "\n" to encode the string of length 1 containing > > a > > > > newline character. > > > > > > > > with respect to (2): > > > > > > > > the type of your top-level expression is String, > > > > which is automatically > > > > print'ed by the interpreter. but print x = > > putStrLn > > > > (show x), so there > > > > is another call to show at this point. to avoid > > this > > > > call, write an IO > > > > action yourself. try the difference between > > > > > > > > putStrLn (hanoi ...) > > > > > > > > and > > > > > > > > print (hanoi ...) > > > > > > > > to see what I mean. > > > > > > > > Last, but not least, I would like to point out a > > > > different aproach to > > > > multiline output which is often used by Haskell > > > > programmers: The worker > > > > functions in this aproach produces a list of > > > > strings, which is joined > > > > together with newlines by the unlines function. > > In > > > > your case: > > > > > > > > hanoi_helper :: ... -> [String] > > > > | ... = ["Move " ++ ...] > > > > | otherwise = hanoi_helper ... ++ > > hanoi_helper > > > > ... > > > > > > > > hanoi n = hanoi_helper 'a' 'b' 'c' n > > > > > > > > and in the interpreter one of these: > > > > > > > > > hanoi 2 -- outputs a list > > > > > mapM_ putStrLn (hanoi 2) -- outputs each > > move > > > > in a new line > > > > > putStrLn (unlines (hanoi 2)) -- same as > > > > previous line > > > > > > > > Tillmann > > > > _______________________________________________ > > > > Haskell-Cafe mailing list > > > > Haskell-Cafe(a)haskell.org > > > > > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > > > > > _______________________________________________ > > > Haskell-Cafe mailing list > > > Haskell-Cafe(a)haskell.org > > > > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > >

1 0

ANNOUNCE: Generic Haskell 1.80 (Emerald)
by Thomas van Noort 14 Apr '08

14 Apr '08

Generic Haskell version 1.80 (Emerald) ====================================== We are happy to announce the fifth release of Generic Haskell, an extension of Haskell that facilitates generic programming. Generic Haskell includes the following features: * type-indexed values -- generic functions that can be instantiated on all Haskell data types. * type-indexed types -- types which are indexed over the type constructors underlying Haskell datatypes. The Generic Haskell compiler takes Generic Haskell source and produces Haskell code. Changes since 1.62 (Diamond) ---------------------------- * Generic views for generic types [1] are now supported. * The implementation of type-indexed types is improved. Download -------- The Generic Haskell compiler is available in source and binary distributions. Binaries for Linux, Windows, and MacOSX are available. These are available from: http://www.generic-haskell.org/compiler.html The documentation is also available separately from that page. For more general information, point your browser to: http://www.generic-haskell.org Why Generic Haskell? -------------------- Software development often consists of designing datatypes, around which functionality is added. Some functionality is datatype specific, whereas other functionality is defined on almost all datatypes in such a way that it depends only on the structure of the datatype. A function that works on many datatypes in this way is called a generic function. Examples of generic functionality include editing, pretty-printing or storing a value in a database, and comparing two values for equality. Since datatypes often change and new datatypes are introduced, we have developed Generic Haskell, an extension of the functional programming language Haskell that supports generic definitions, to save the programmer from (re)writing instances of generic functions. The original design of Generic Haskell is based on work by Ralf Hinze. Pleasant programming, The Generic Haskell Team at Utrecht University info(a)generic-haskell.org [1] Thomas van Noort. Generic views for generic types. Master's thesis, Utrecht University, 2008.

5 10

Type families and GADTs in 6.9
by Dan Doel 14 Apr '08

14 Apr '08

Hello, I've been playing around with type families off and on in 6.8, but, what with the implementation therein being reportedly incomplete, it's hard to know what I'm getting right and wrong, or what should work but doesn't and so on. So, I finally decided to take the plunge and install 6.9 (which, perhaps, isn't yet safe in that regard either, but, such is life :)). But, when I loaded up one of my programs, I got a type error. The subject is inductively defined tuples: ------------------------------------- {-# LANGUAGE GADTs, TypeFamilies, EmptyDataDecls, TypeOperators #-} data Zero data Succ n data Nat n where Zero :: Nat Zero Succ :: Nat n -> Nat (Succ n) data FZ data FS a data Fin fn n where FZ :: Fin FZ (Succ n) FS :: Fin fn n -> Fin (FS fn) (Succ n) f0 = FZ f1 = FS f0 f2 = FS f1 -- ... etc. data Nil data t ::: ts type family Length ts :: * type instance Length Nil = Zero type instance Length (t ::: ts) = Succ (Length ts) type family Lookup ts fn :: * type instance Lookup (t ::: ts) FZ = t type instance Lookup (t ::: ts) (FS fn) = Lookup ts fn infixr 4 ::: data Tuple ts where ZT :: Tuple Nil (:::) :: t -> !(Tuple ts) -> Tuple (t ::: ts) {- This type signature gets complained about in 6.8, but it seems like a sensible one: proj :: (Length ts ~ n) => Fin fn n -> Tuple ts -> Lookup ts fn Indexing the tuple by its length is also an option (which works). In any case, the code doesn't even work with the lenient 6.8 signature: -} proj :: Fin fn n -> Tuple ts -> Lookup ts fn proj FZ (v ::: vs) = v proj (FS fn) (v ::: vs) = proj fn vs ------------------------------------- The overall goal being Haskell-alike tuples with a single projection function that works for all of them, without having to use template haskell for instance (fst = proj f0, snd = proj f1, etc.). However, proj results in a type error: Occurs check: cannot construct the infinite type: t = Lookup (t ::: ts) fn In the pattern: v ::: vs In the definition of `proj': proj FZ (v ::: vs) = v Oddly (to me), if I reverse the clauses, the compiler doesn't complain about the FS case, still complaining about FZ. Now, my thought process here is that the pattern match against FZ (the value) requires fn to be FZ (the type), which should tell the compiler to solve "t ~ Lookup (t ::: ts) FZ" which is, of course, the first instance above. Am I doing something wrong, or have I bumped into as-yet-unimplemented functionality? Thanks for your time and help. -- Dan

3 3

Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
by Daniel McAllansmith 14 Apr '08

14 Apr '08

On Mon, 14 Apr 2008 13:32:07 Chris Smith wrote: > On Sun, 13 Apr 2008 16:06:43 -0700, Adam Langley wrote: > > On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell <johan.tibell(a)gmail.com> > > > > wrote: > >> * Using a different set of data types would work better. > > > > Give that this is Haskell, I'd suggest more types ;) > > > > HTTP headers aren't just strings and, at the risk of tooting my own > > horn, I'll point to the Headers structure in [1]. > > Wait, I'm not sure I agree here. How are headers not just strings? Headers, at least their values, aren't strings. The specification says so. I think headers should be represented by something more specific than a string. > By > assuming that, are we guaranteeing that anything using this interface > cannot respond gracefully to a client that writes malformed headers? Having explicit types for headers doesn't preclude trying to handle messages with malformed headers. Soldiering on in the face of malformed messages as a general strategy is pretty dubious in my opinion. In the specific cases where you've determined it is necessary you want to be able to register a work-around parser for that section of the message, and be able to tell that it has been used. A decent framework can supply a catalogue of commonly required work-arounds. > > Another perspective: there is unnecessary variation there in how > interfaces are represented. If I'm looking for a header, and I know its > name as a string, how do I look for it? Well, apparently it's either a > named field (if it's known to the interface) or in the "other" section > (if not). So I write a gigantic case analysis? But then suppose the > interface is updated later to include some headers that popped up > unofficially but then are standardized in a future RFC. (This is not too > odd; lots of REST web services invent new headers every day, many of > which do things that make sense outside of the particular application.) > Does old code that handled these headers stop working, just because it > was looking in the "other" section, but now needs to check a field > dedicated to that header? I don't like the idea of having a fixed enumeration of methods or headers. You need to be able to define new methods and headers at will, and ideally have the usage of headers constrained to valid contexts. This suggests to me type classes that establish a 'can occur in' relationship between request/response, method and a given general/request/response/entity header. By importing new method or header data type, appropriate type class instances and registering an appropriate message parser extension you can mix and match which headers and methods you support. GET and HEAD are the only ones that MUST be supported after all. Daniel

1 0

install trouble with SDL on win32+cygwin
by Conal Elliott 13 Apr '08

13 Apr '08

I'm trying to install the SDL package (on win32+cygwin), and configure isn't able to find my SDL.dll, though it's on my PATH. Any ideas? - Conal bash-3.2$ cabal install SDL 'SDL-0.5.3' is cached. [1 of 1] Compiling Main ( Setup.lhs, dist\setup/Main.o ) Linking dist\setup\setup.exe ... Configuring SDL-0.5.3... checking for sdl-config... no checking for sdl11-config... no configure: error: *** SDL not found! Get SDL from www.libsdl.org. If you already installed it, check it's in the path. If problem remains, please send a mail to the address that appears in ./configure --version indicating your platform, the version of configure script and the problem. cabal.exe: Error: some packages failed to install: SDL-0.5.3 failed during the configure step. The exception was: exit: ExitFailure 1 bash-3.2$ which SDL.dll /cygdrive/c/WINDOWS/system32/SDL.dll bash-3.2$

4 6

more on my ghc package issues
by Galchin, Vasili 13 Apr '08

13 Apr '08

Hello, I "unregistered" unix-2.3.0.0. Now I cannot rebuild the Unix package. Please see the below log: vigalchin@ubuntu:~$ ghc-pkg latest unix unix-2.2.0.0 vigalchin@ubuntu:~$ ghc-pkg describe unix name: unix version: 2.2.0.0 license: BSD3 copyright: maintainer: libraries(a)haskell.org stability: homepage: package-url: description: This package gives you access to the set of operating system services standardised by POSIX 1003.1b (or the IEEE Portable Operating System Interface for Computing Environments - IEEE Std. 1003.1). . The package is not supported under Windows (except under Cygwin). category: author: exposed: True exposed-modules: System.Posix System.Posix.DynamicLinker.Module System.Posix.DynamicLinker.Prim System.Posix.Directory System.Posix.DynamicLinker System.Posix.Env System.Posix.Error System.Posix.Files System.Posix.IO System.Posix.Process System.Posix.Process.Internals System.Posix.Resource System.Posix.Temp System.Posix.Terminal System.Posix.Time System.Posix.Unistd System.Posix.User System.Posix.Signals System.Posix.Signals.Exts System.Posix.Semaphore System.Posix.SharedMem System.Posix.MQueue hidden-modules: import-dirs: /usr/local/lib/unix-2.2.0.0/ghc-6.8.2 library-dirs: /usr/local/lib/unix-2.2.0.0/ghc-6.8.2 hs-libraries: HSunix-2.2.0.0 extra-libraries: util dl extra-ghci-libraries: include-dirs: /usr/local/lib/unix-2.2.0.0/ghc-6.8.2/include includes: HsUnix.h execvpe.h depends: base-3.0.1.0 directory-1.0.0.0 hugs-options: cc-options: ld-options: framework-dirs: frameworks: haddock-interfaces: /usr/local/share/doc/unix-2.2.0.0/html/unix.haddock haddock-html: /usr/local/share/doc/unix-2.2.0.0/html vigalchin@ubuntu:~$ vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0$ runhaskell Setup.hs configure unknown package: unix-2.3.0.0 In my .cabal file, I have specified the version as 2.2.0.0, 2.3.0.0 and 2.4.0.0 all with the same results: "unknown package: unix-2.3.0.0" Vasili

4 6