June 2008 - Haskell-Cafe

Re: [Haskell-cafe] Re: How to do this in FP way?
by Thomas Davie 16 Jun '08

16 Jun '08

On 16 Jun 2008, at 19:24, Achim Schneider wrote: > Thomas Davie <tom.davie(a)gmail.com> wrote: > >> >> On 16 Jun 2008, at 18:28, Achim Schneider wrote: >> >>> Thomas Davie <tom.davie(a)gmail.com> wrote: >>> >>>>> >>>>> One half of all Haskell coders will tell you that mutable state >>>>> isn't a >>>>> good starting point to learn Haskell, the other half will tell you >>>>> the same because they want to be cool kids, too. >>>> >>>> And the one left over will point out that he asked how to do this >>>> the FP way, not the imperative way? >>>> >>> There's no difference, as you can't do time-accounting non-strict >>> and still expect it to give meaningful results: I'm merely trying >>> to be helpful. None of the other solutions allow for the IO Monad. >> >> Firstly, I'd phrase that differently -- the IO Monad doesn't allow >> for the other solutions -- the other solutions are the truly >> functional ones. Secondly, I'm curious as to why you think that the >> two are incompatible, are you saying that for any meaningful kind of >> computation we need to resort to IORefs? I'd strongly contest that >> idea. >> > We have to resort to IO actions to get the time, and to IORefs because > we need to chain up different calls to getCurrentTime using the IO > Monad. The rest of the program can work with whatever you like best. And in what way is this incompatible with either FRP as pierre suggested, or with generating an infinite list of times at which we call the function, and scanning it to find the differences? Bob

2 1

ANN: Haddock Trac
by David Waern 16 Jun '08

16 Jun '08

Hi everyone, there's now a Haddock bug-tracker and wiki at http://trac.haskell.org/haddock. Please use it to submit bug reports and feature requests! David

2 1

C-program calling Haskell program?
by Taepke, Bob 16 Jun '08

16 Jun '08

Hello, I am very new to Haskell, and I work in Windows XP. Can anyone please point me to a working C / Haskell program pair that does the following: 1) The C routine passes one or more scalars, arrays, or matrices to the Haskell routine. 2) The Haskell routine reads a comma-delimited, ASCII file from the path, C:\my_directory\input_data\. 3) The Haskell routine writes a comma-delimited, ASCII file to the path, C:\my_directory\output_data\. 4) The Haskell routine returns to the C routine one or more scalars, arrays, or matrices. 5) For what it's worth, I'm only using the C-routine as an interface between MATLAB and Haskell, because MATLAB can call C-routines. Has anyone written C / Haskell code that does the above tasks? If so, would you please be willing to pass it along to me? Thank you! Bob [CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this email is proprietary to Medtronic and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please delete this mail from your records. To view this notice in other languages you can either select the following link or manually copy and paste the link into the address bar of a web browser: http://emaildisclaimer.medtronic.com

1 0

FunPtr error?
by Galchin, Vasili 16 Jun '08

16 Jun '08

Hello, I am getting what is to me a mysterious error in a test case that I am writing: vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0/tests/timer$ runhaskell Setup.lhs build Preprocessing executables for Test-1.0... Building Test-1.0... [1 of 1] Compiling Main ( ./timer.hs, dist/build/timer/timer-tmp/Main.o ) ./timer.hs:11:45: Not in scope: data constructor `FunPtr' It seems like the compiler is complaining about the lack of FunPtr in it's symbol table but System.Posix is imported: module Main where import System.Posix import Foreign import Foreign.C import Foreign.Ptr main = do let event = Sigevent{sigevFunction=(FunPtr (notifyFunc))} <<<<<< error here timerId <- timerCreate Clock_Realtime Nothing timerDelete timerId return () notifyFunc :: Sigval -> IO () notifyFunc sigval = do putStrLn "timer POP!!!!!!!" return () I am probably looking right at the answer and not seeing it. ?? Thanks, Vasili

5 15

monomorphism restriction
by Rex Page 16 Jun '08

16 Jun '08

Definition of f: f = foldr (+) 0 Types: 0 :: (Num t) => t foldr (+) 0 :: Num a => [a] -> a f :: [Integer] -> Integer Please remind me, again, of the advantages of f being something different from the formula defining it. - Rex Page

5 6

Lazy IO.
by Sebastiaan Visser 16 Jun '08

16 Jun '08

Hi, I've got a question about lazy IO in Haskell. The most well known function to do lazy IO is the `hGetContents', which lazily reads all the contents from a handle and returns this as a regular [Char]. The thing with hGetContents is that is puts the Handle in a semi-closed state, no one can use the handle anymore. This behaviour is understandable from the point of safety; it is not yet determined when the result of hGetContents will actually be computed, using the handle in the meantime is undesirable. The point is, I think I really have a situation in which I want to use the handle again `after' a call to hGetContents. I think I can best explain this using a code example. readHttpMessage :: IO (Headers, Data.ByteString.Lazy.ByteString) readHttpMessage = do myStream <- <accept http connection from client> request <- hGetContents myStream header <- parseHttpHeader request bs <- Data.ByteString.Lazy.hGetContents myStream return (header, body) The Data.ByteString.Lazy.hGetContents in the example above obviously fails because the handle is semi-closed. So, what I am trying to do here is apply a parser (on that consumes Char's) to the input stream until it has succeeded. After this I want to collect the remainings of the stream in a lazy ByteString, or maybe even something else. I tried to open the handler again using some internal handle hackery, but this failed (luckily). In the module GHC.IO there is a function `lazyRead' that more or less seems to do what I want. But I'll guess there is a good reason for not exporting it. Does anyone know a pattern in which I can do this easily? Thanks, -- Sebastiaan

8 13

Design your modules for qualified import
by Johan Tibell 16 Jun '08

16 Jun '08

Hi! The last two weeks I've seen two new packages that add suffixes to identifiers instead of relying on them being imported qualified to distinguish them from identifiers in other modules. This is not a new thing in Haskell community and there are examples of this practice in libraries shipped with GHC. It is also common in papers (for good reasons as we will see later). Atomic channels and variables under Control.Concurrent.* are examples of using a prefix as a namespacing tool. Let me reiterate the arguments [1,2] against this practice and also speculate why this practice is more common in Haskell than in e.g. Python, Java or Ruby. * Cons of including a namespace prefix/suffix in identifiers 1. From experience these prefixes/suffixes tend to be short and non-descriptive, typically just one letter e.g. foldU or elemB. Very frequently used functions that every Haskell programmer is likely to use often can have shorter name as the cost of memorizing them is amortized over all their uses. Examples of short names that most Haskell programmers know by heart is map, fold*, etc. Given that your library won't see the same use as these functions your functions need more descriptive names (or in this case use a qualified import that makes them more descriptive e.g. Array.fold). 2. If your modules are imported qualified the suffix is redundant and thus wastes space. Consider for example foldU imported qualified from the module Data.Array as Array.foldU. Array.fold would have been better in this case. * Pros of using qualified imports 1. Your code will be more robust against additions to modules you depend on. Consider this snippet: import Some.Module -- An utility function that the author of the above module forgot to include. foo = ... Now the author of Some.Module releases a new version of his or her package which include `foo' and your code no longer compiles. If you have no imports on the form import Some.Module your package can specify more relaxed version dependencies on other packages [3]. 2. It's easier to see from where an identifier is imported. Just check the functions module prefix (e.g. Array in Array.foo). If you renamed the import using import Foo as F you might have to check the import list. * Explicit, unqualified imports An alternative to qualified imports that shares some of benefits is to import names unqualified but explicitly enumerate the function names e.g. import Some.Module (foo, bar) It is still not immediately obvious what module a name refers too when using this style (point 2 under pros above) but it is at least easier to find than when implicitly importing all names from a module. This is my current preference for infix operators as they look quite ugly qualified with a module name. It might also make sense if a few functions (e.g. parser combinators) are used a lot in the same module (e.g. an HTTP parser). * Why is this practice common in Haskell Here are some guesses: 1. It's common in papers. However, papers and libraries are quite different. The former usually build up a small vocabulary and having short names is a big win. Papers rarely make use of the module system at all. The latter are included as pieces of large programs and their names need to be adjusted accordingly. 2. It's the default. You have to add "qualified" to all your imports to make them qualified. In most language imports are qualified by default. I think the latter would have been a better choice but we have to live with the current design so bite the bullet and add those qualified keywords to your imports. 3. Lack of common interfaces. An example would be two different set implementations that essentially have the same interface but since there is no explicitly shared interface, defined using a type class, you sometimes end up with different names. The lack of type families might explain why e.g. collection classes don't share interfaces. 4. Haskell is a very expressive language. You can often write a whole function definition on one line! Adding those module qualifications makes your code slightly longer and it might just break your beautiful one liner into two lines. * Summary Whenever you write a library design it so it works well with qualified imports. That means leaving namespacing issues to the module system. Try to think of how code using your functions will look like if it uses them qualified. * References 1. http://www.haskell.org/haskellwiki/Import_modules_properly 2. http://www.haskell.org/haskellwiki/Qualified_names 3. See section 2 Version numbers - http://www.haskell.org/haskellwiki/Library_versioning_policy Cheers, Johan

22 40

Memory profiling
by Pieter Laeremans 16 Jun '08

16 Jun '08

Hi, Which tools do you recommand for memory profiling haskell programs on a *nix system. I'm using haskell to develop a CGI program/script. The application has to be deployed on shared hosting infrastructure. Since I would like to be a good citizen , I would need to meassure the maximum amount of memory allocated to the program during execution. The best I can do now is look at top but that 's not satisfactory. thanks, Pieter -- Pieter Laeremans <pieter(a)laeremans.org>

2 1

Documenting the impossible
by Andrew Coppin 15 Jun '08

15 Jun '08

I have a small idea. I'm curios if anybody else thinks it's a good idea... How about a {-# IMPOSSIBLE #-} pragma that documents the fact that a particular point in the program *should* be unreachable? For example, you look up a key in a Map. You know the key is there, because you just put it there yourself two seconds ago. But, theoretically, lookup returns a Maybe x so - theoretically - it's possible it might return Nothing. No matter what you do, GHC will insert code to check whether we have Just x or Nothing, and in the Nothing case throw an exception. Obviously there is no way in hell this code path can ever be executed. At least, assuming your code isn't broken... This is where the pragma comes in. The idea is that you write something like case lookup k m of Just v -> process v Nothing -> {-# IMPOSSIBLE "lookup in step 3" #-} When compiled without optimisations, the pragma just causes an exception to be thrown, rather like "error" does. When compiled with optimisations, the whole case alternative is removed, and no code is generated for it. (And if the impossible somehow happens... behaviour is undefined.) So you test your program with your code compiled unoptimised, and when you're "sure" the impossible can't happen, you tell the compiler to remove the check for it. (Actually, it would possibly be a good idea to have a switch to turn this on and off seperately if needed...) Does anybody think this is a useful idea? If so I'll add a feature request ticket to the GHC Trac. But I want to see if folks like the idea first... (I was thinking the message in the pragma would be what gets displayed on screen, along with some auto-generated location info. Just a module name and line number ought to be sufficient...)

12 16

External query interface to HackageDB?
by Dimitry Golubovsky 15 Jun '08

15 Jun '08

Hi, Is there any way to query the latest version of a particular package stored on Hackage, that was successfully built? I mean, not _how_ to do that (I have some ideas that I have to download directory listings, looking for failure logs, etc.), but is there any tool or interface already available that does similar things? Unfortunately, tarfiles provided on Hackage (like 00-index.tar.gz) do not help, e. g. BerkeleyDB failed to build in all three versions, yet its all cabal files are included in the tarball: tar tvf 00-index.tar.gz ... -rw-r--r-- www-data/www-data 1055 2007-04-06 13:03 ./BerkeleyDB/0.1/BerkeleyDB.cabal -rw-r--r-- www-data/www-data 1061 2007-04-06 16:59 ./BerkeleyDB/0.2/BerkeleyDB.cabal -rw-rw-r-- www-data/www-data 1236 2008-01-11 14:42 ./BerkeleyDB/0.3/BerkeleyDB.cabal I remember, in the past, HackageDB was expected to become a database of some sort: is there any database-like backend that would accept queries, other than just parsing Apache dir listings? My final goal, given some master-list of package names, to be able to retrieve latest succesfully built (not just uploaded) releases from Hackage Thanks. -- Dimitry Golubovsky Anywhere on the Web

2 1