- Haskell-Cafe - Haskell.org

Foralls in records
by Adde 15 Mar '07

15 Mar '07

Hi. I'm experimenting with implementing database transactions as monads but I'm getting stuck on how to store a generic connection (only constrained by a typeclass) inside the transaction. The reason I'm doing it this way is that the connection could be a different kind of structure depending on what database the transaction is using. The goal is to enable all functions using the monad to extract the connection using getConnection. I realise I could probably get it running by adding a type parameter for the connection type to TransactionT and Transaction but I feel I shouldn't have to. All the compiler needs to know is that the contained value conforms to the interface of Connection. <code> data TransactionT = forall c. (Connection c) => TransactionT c data Transaction a = Transaction (TransactionT -> (a, TransactionT)) instance Monad Transaction where ... getConnection :: Transaction c getConnection = Transaction (\t@(TransactionT c) -> (c, t)) class Connection c where connectionExecute :: c -> String -> Transaction () execute :: String -> Transaction () execute s = connectionExecute getConnection s </code> I'm getting the following error: Couldn't match expected type `c' (a rigid variable) against inferred type `c1' (a rigid variable) `c' is bound by the type signature for `getConnection' at Database.hs:19:29 `c1' is bound by the pattern for `TransactionT' at Database.hs:20:33-46 In the expression: c In the expression: (c, t) In a lambda abstraction: \ (t@(TransactionT c)) -> (c, t)

5 11

Make strict (IO String) lazy
by Henning Thielemann 15 Mar '07

15 Mar '07

On the one hand, in the standard libraries there are functions like readFile, getContents, hGetContents which read a file lazily. This is often a nice feature, but sometimes lead to unexpected results, say when reading a file and overwriting it with modified contents. Unfortunately the standard libraries provide no functions for strict reading, and one has to do this manually. On the other hand, when I write some IO function that returns a String, I easily end up with a function which produces the String in a strict way. (Say I call some shell commands and concatenate their outputs.) What is the preferred way to turn a strict (IO String) into a lazy one? forkIO? forkOS? How would one derive readFile from a hypothetical strictReadFile?

3 2

SYB vs HList (again)
by S. Alexander Jacobson 15 Mar '07

15 Mar '07

Right now I am looking at using either SYB (Scrap Your Boilerplate) or HList Records to eliminate boilerplate for: * parsing URLEncoded strings into application data structures * generating XML/JSON from application data structures * handling adding new fields to serialized data structures * creating indexed collections of application data structures I am looking for insights from people here on which approach they think is better and why. Here are my current thoughts on the issue == Both HList and SYB require data structures redesign == HLists require you to define Labels and basically only use label values that are themselves either scalar or HLists. SYB basically requires the same thing except that you use data/newtype to define labels instead of HLists more cumbersome label constructions. == Defaults: HList gives you compile time errors, SYB only runtime errors == SYB does not seem to provide a way of having the compiler tell you that you are accessing a field that is unavailable in the type. HList will give you a type error if you do that. I don't know exactly how HList handles default values but I assume you can restrict use of those values to explicit deserialization contexts. Is that correct? == HList allows more informality == With HList you can specify the type of a record ad hoc using obj::(Record Foo .*. Bar .*.Baz). SYB requires that you define data structures in separate data declarations. It would be really nice if there was some way to tell Haskell that HLists have no more fields than the ones you happen to be getting and setting in your code. Effectively that would mean you get data structure inference not just function type inference which would be really cool! That is probably not possible but it couldn't hurt to ask (Oleg?). == SYB doesn't require template haskell to make it usable == With SYB you create field labels using newtype (or data) declarations e.g. data Salary = S {salary::Float} With HList, label declarations are really verbose e.g. data SalaryLabel deriving(Typeable) type Salary = Field (Proxy SalaryLabel) Int salary = proxy :: Proxy FooLabel You can make this more concise using TemplateHaskell but TH looks alien and adds fear to the use of any code. == Performance issues == SYB requires a linear traversal of all field elements using dynamic to get or transform a value. HList traverses an HCons list. I don't how bad this is as compared with traditional data structure access using pattern matching or field labels. My current bias is towards using HList because if we are going to force a conversion to a new data structure convention I'd rather have the typesystem on my side. With SYB it is too easy to let haskell field labels creep in to your data definitions and end up with subtle errors to correct. Any opinions on these issues would be very appreciated. -Alex-

2 1

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 14 Mar '07

14 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 14 Mar '07

14 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