March 2007 - Haskell-Cafe

Takusen and strictness, and perils of getContents
by oleg＠pobox.com 15 Mar '07

15 Mar '07

Takusen permits on-demand processing on three different levels. It is specifically designed for database processing in bounded memory with predictable resource utilization and no resource leaks. But first, about getContents. It has been mentioned a while ago that getContents should be renamed to unsafeGetContents. I strongly support that suggestion. I believe getContents should be used sparingly (I personally never used it), and I believe it cannot give precise resource guarantees and is a wrong model for database interfaces. I will not dwell on the fact that getContents permits IO to occur while evaluating pure code -- which is just wrong. There is a practical consequence of this supposedly theoretical impurity: error handling. As the manual states ``A semi-closed handle becomes closed: ... if an I/O error occurs when reading an item from the handle; or once the entire contents of the handle has been read.'' That is, it is not possible to tell if all the data from the channel have been read or an I/O error has interfered. It is not possible to find out any details about that I/O error. That alone disqualifies getContents from any serious use. Even more egregious is resource handling and that business with semi-closed handles, which is a resource leak. Interfacing with a database requires managing lots of resources: database connection, prepared statement handle, statement handle, result set, database cursor, transaction, input buffers. Takusen was specifically designed to be able to tell exactly when a resource is no longer needed and can be _safely_ disposed of. That guarantee is not available with getContents -- the resources associated with the handle are disposed when the consumer of getContents is finished with it. Since the consumer may be pure code, it is impossible to tell when the evaluation finishes. It may be in a totally different part of the code. To get more predictability, we have to add seq and deepSeq -- thus defeating the laziness we supposedly have gained with getContents, and hoping that two wrongs somehow make it right. Regarding Takusen: it is designed for incremental processing of database data, on three levels: -- unless the programmer said that the query will yield small amount of data, we don't ask the database for all of the result set at the same time. We ask to deliver data in increments of 10 or 100 rows (the programmer may tune the amount). The retrieved chunk is placed into pre-allocated buffers. -- the retrieved chunk is given to an iteratee one row at a time. The iteratee may at each point specify that it has had enough. The processing immediately stops, no further chunks are retrieved and all resources of the query are disposed of. -- Alternatively, Takusen offers the cursor-based interface, with getNext and getCurrent methods. The rows are retrieved on-demand in chunks. The interface is designed to restrict operations on a cursor to a region of code. Once the region is exited (normally or by exception), all associated resources are disposed of because they are statically guaranteed to be unavailable outside the region. Because the moments of resource allocation and deallocation are so well known, Takusen can take care of all of it. The programmer will never have to worry about resource leaks, deallocations, etc. A bit of experience: I have implemented a Web application server in Haskell, using Takusen as a back end. The server runs as a FastCGI dynamic server, retrieving a chunk of rows from the database, formatting the rows (e.g., in XML), sending them up the FastCGI interface and ultimately to the client, coming back for the next chunk. The advantage of that stream-wise processing is low latency, low memory consumption, and client limiting the database retrieval rate. Typical requests routinely ask for thousands of database rows; the server runs continuously serving hundred of requests, in constant memory. The executable is 2.6 MB in size (GHC 6.4.2); the running process takes VmSize of 6608 kB, including VmRSS of 3596 kB and VmData of 1412 kB. The code has not a single unsafePerformIO (and aside from an S-expression parsing code I inherited) I used not a single strictness annotation. The line count (including comments) is 7500 lines in 30 files.

3 6

Jaskell, has anybody tried it?
by Lars Johansson 15 Mar '07

15 Mar '07

Hello, I have installed the Jaskell libraries for java under Eclipse, but I can't get it running and the documentation on installing is really sparse. So any help I will apprreciate. Or any ideas! Sincerely Lars Johansson _________________________________________________________ Flyger tiden iväg? Fånga dagen med Yahoo! Mails inbyggda kalender. Dessutom 250 MB gratis, virusscanning och antispam. Få den på: http://se.mail.yahoo.com

1 0

principle types
by Vikrant 15 Mar '07

15 Mar '07

Hi, I can understand why principle type of map is map :: (a -> b) -> [a] -> [b] , I would interpret this as "map takes a function of type a->b and a list of type [a] as arguments and returns a list of type [b]" but it is going somewhat beyond my imagination why principle type of map map is (map map)::[a -> b] -> [[a] -> [b]] I am able to interpret the expressions "[a -> b] -> [[a] -> [b]]" vaguely... does this mean that 'map map' takes list of functions of type (a->b) and returns list of functions of type ([a]->[b]) if yes ..how do I derive it from basic type declaration of map? Thanks in advance Vikrant

4 4

Re: [Haskell] small boys performance
by Dan Piponi 14 Mar '07

14 Mar '07

On 3/14/07, Andrzej Jaworski <himself(a)poczta.nom.pl> wrote: > I am glad you are interested Dan. > ... > I do not intend to bore anybody with differential geometry but as I was > pushed that far let me add that if Haskell was made to handle Riemannian > geometry it could be useful in next generation machine learning research > where logic, probability and geometry meet. I believe that you can probably handle (pseudo-)Riemannian geometry in the framework sketched here: http://sigfpe.blogspot.com/2006/09/practical-synthetic-differential.html That only goes as far as playing with vector fields and Lie derivatives but I think that forms and tensors should fit just fine into that framework. There's a simple way to use types to represent tensor products, and that's sketched here: http://sigfpe.blogspot.com/2006/08/geometric-algebra-for-free_30.html (Forget that that's about geometric algebra, the thing I'm interested in is the tensor products.) So I'm guessing there's a way of combining these to give a framework for (pseudo-)Riemannian geometry. But it'd only be a good framework for answering certain types of questions - in particular for things like numerical simulation. The important thing is that you'd be able to read off accurate numerical values of quantities like curvatures without any need for symbolic algebra. -- Dan

2 1

Read Instance for UArray won't port to linux
by SevenThunders 14 Mar '07

14 Mar '07

I have the pleasure of porting a good sized Haskell application to linux. So far the Haskell code has compiled without incident, however some code that I hacked to implement a Read instance for Unboxed Arrays does not compile on linux even though it compiles just fine on Windows XP in Haskell 6.6. The code reads as, instance Read (UArray Int Double) where readsPrec p = readParen (p > 9) (\r -> [(array b as :: UArray Int Double, u) | ("array",s) <- lex r, (b,t) <- reads s, (as,u) <- reads t ]) The error in linux is: Illegal instance declaration for `Read (UArray Int Double)' (The instance type must be of form (T a b c) where T is not a synonym, and a,b,c are distinct type variables) In the instance declaration for `Read (UArray Int Double)' Why does it want three parameters for the instance type? I am baffled by this. -- View this message in context: http://www.nabble.com/Read-Instance-for-UArray-won%27t-port-to-linux-tf3400… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

8 10

How to convert Num a => a to Int
by Sergey Perminov 14 Mar '07

14 Mar '07

As a beginner I want to implement such fuction: plusSecs :: Num a => a -> ClockTime -> ClockTime plusSecs n = addToClockTime ( secTimeDiff (n) ) where secTimeDiff n = TimeDiff { tdYear = 0, tdMonth = 0, tdDay = 0, tdHour = 0, tdMin = 0, tdSec = n, tdPicosec = 0 } The problem here that it's type signature is illegal because tdSec of System.Time.TimeDeff must be Int type only, but I wish to apply plusSecs to any Num or (at least) any Integral type number. The reason for this - to have less compilation errors (that are mostly about error types) and more abstractedness (generality) of this function. So, the question is: Is it possible somehow to convert any Num (or at least Integral) to Int. Please, tell me if I don't get smth in Haskell type system.

3 2

Re: small boys performance
by apfelmus＠quantentunnel.de 14 Mar '07

14 Mar '07

-- redirected from haskell.general Andrzej Jaworski wrote: > As I regretfully pointed out earlier in [Fwd: Re: Computer Language > Shootout] > large search and simulations are not for Haskell. This is equally true with > GHC 6.5 http://eric_rollins.home.mindspring.com/haskellAnt.html. Indeed, directly translated ML code is not for Haskell. Or did you really expect Array (Int,Int) Double, ubiquitous tail recursion and accumulating nodes at the end of a list (nextPath = path ++ [nextCity]) to give you simulation wonders? Btw, there are a lot of opportunities for abstraction, separation of concerns and reuse in the code. There are much to many to list them all, but here are few: - Most importantly, iterations are best separated into generation and selection: bestPath = last . iterate (evolve) There is really no need (and it hurts performance, you know) to have this parameter hell. - By grouping paths with their total scores like in data Path = Path { nodes :: [Node], score :: Int } you can define a very convenient best :: Path -> Path -> Path that chooses the one with the greater score. More general, you can define maxBy :: (a -> Double) -> a -> a -> a maxBy f x y if f x >= f y then x else y - Considering a minor stylistic point, incrs = [ (fromIntegral boost) | n <- pairs ] pairsWithInc = zip pairs incrs is best known as pairsWithInc = zip pairs $ repeat (fromIntegral boost) - Abstraction from the concrete graph implementation enables switching from Array (Int,Int) Double to a sparse representation if demanded, namely a nested IntMap (IntMap Double). - etc. > calculating a tensors with symbolic indices (without components) > so that one could have components calculated for specific cases on the end > of general calculation. http://www.nt.ntnu.no/users/haugwarb/Programming/haskell_automatic_differen… Regards, apfelmus

1 0

Parallelism on concurrent?
by Dusan Kolar 14 Mar '07

14 Mar '07

Hello all, I'm googling around haskell.org to get some deeper knowledge about Control.Parallel.Strategies than it is presented on http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Parallel… BTW, could someone point me to some more deeper doc. about it? During googling I've discovered that since GHC 6.6, par, forkIO, and forkOS should make the stuff run in parallel if I have more than one CPU core. Is that right? I think not, because on my machine only par makes the things run in parallel and only during the computation (GC runs in a single thread). If it should work, how can I verify that my installation is correct? If it should not work, will it be working someday? Thanks for your patience, responses, and tips Dusan

6 8

c2hs and pthreadtypes.h
by Magnus Therning 14 Mar '07

14 Mar '07

I'm trying to use c2hs but get stuck when including sys/types.h (though the problem really resides in pthreadtypes.h): % ./Setup.hs build -v Preprocessing executables for kowasu-0.1... /usr/bin/c2hs -C -D__GLASGOW_HASKELL__=606 -C -Icsrc -o src/Kowasu/PTrace.hs src/Kowasu/PTrace.chs c2hs: Error in C header file. /usr/include/bits/pthreadtypes.h:69: (column 6) [FATAL] >>> Syntax error! The symbol `;' does not fit here. The part of pthreadtypes.h where it chokes seems to be 65 __extension__ union 66 { 67 int __spins; 68 __pthread_slist_t __list; 69 }; 70 } __data; 71 char __size[__SIZEOF_PTHREAD_MUTEX_T]; 72 long int __align; 73 } pthread_mutex_t; Any pointers on how to solve this? (Besides manually resolving all defined types down to the C builtins.) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus(a)therning.org Jabber: magnus.therning(a)gmail.com http://therning.org/magnus

4 4

Defining types (newbie)
by John Fouhy 14 Mar '07

14 Mar '07

Hi all, I studied Haskell a few years ago at uni, but I haven't used it since, so I'm a bit rusty. But I've been inspired by this paper: http://citeseer.ist.psu.edu/585421.html which talks about building a combinator language for financial contracts, and which uses Haskell as the implementation language. ...anyway. Say I have a data type: data Thing = Thing { field_one :: String, field_two :: String, field_three :: Integer } I'd like to build a datatype that represents comparison rules on Things. A comparison rule would be something like "thing1.field_two == thing2.field_two" or "thing1.field_three > thing2.field_three". If I was writing python, I might do this as: class ThingCompare: def __init__(self, op, field, thing1, thing2): self.op = op self.field = field I could evaluate instances of ThingCompare as: def evalThingCompare(tc, thing1, thing2): return tc.op(getattr(thing1, tc.field), getattr(thing2, tc.field)) In Haskell, I envisage writing something like: data ThingCompare = TC Op Field So that if I had: eq x y = x == y then I could create a ThingCompare by saying: tc = eq field_two And I could evaluate my ThingCompares by defining: evaltc :: ThingCompare -> Thing -> Thing -> Bool evaltc (TC o f) t1 t2 = o (f t1) (f t2) But I can't figure out what types "Op" and "Field" should be. Any suggestions? Am I on the wrong track? (have I been corrupted by python's dynamic typing? :-) ) -- John.

4 7