March 2008 - Haskell-Cafe

Opening Windows .lnk Files
by Dominic Steinitz 22 Mar '08

22 Mar '08

Does anyone know how to do this? If I open a file on Windows e.g. "asn_application.h.lnk" then I get the link data rather than the data in the linked file. Thanks, Dominic.

2 2

Re: [Haskell-cafe] AMQP framing layer: design help requested.
by Paul Johnson 22 Mar '08

22 Mar '08

Dean Herington wrote: > At 6:41 PM -0700 3/21/08, Adam Langley wrote: >> >> Also >>> getter <- fmap (amqpGetTable !) getWord8 >>> getter >> >> is just >> >> > fmap (amqpGetTable !) getWord8 > > I don't think so. Aren't there two "gettings": the first to get the > "type" byte and the second to get the item? > Yes. I didn't use it because it seemed obfuscated, but in fact the point-free version is > fmap (amqpGetTable !) getWord8 >>= id And I've also got an AmqpWire class similar to Dean's AmqpValue class. But both of these miss the point (which is why I didn't clutter up my simplified explanation with them). I'm looking for an alternative to the honking big AmqpVariant and AmqpArray types. I think I want something along the lines of: > class (Binary v) => VariantClass v where > typeCode :: v -> Word8 > fromVariant :: AmqpVariant -> Maybe v > > newtype AmqpVariant = forall a . (VariantClass a) => Variant a > > newtype AmqpArray = forall a . (VariantClass a) => AmqpArray [a] But I can't see how to write "fromVariant". I'm also unsure what the "amqpGet" and "amqpPut" methods might look like. Or maybe these two types are actually the best design. They do let you pattern-match on the contents. Extracting the contents of a variant from the design above would be something like: > processVariant (Variant v) = > case typeCode v of > 0x01 -> processWord8 $ fromJust $ fromVariant v > 0x02 -> ... and so on. Compare this with: > processVariant (VariantWord8 v) = processWord8 v > processVariant (VariantWord16 v) = processWord16 v > ... and so on. What do you think? Paul.

2 1

[GSoC] Plugins for GHC
by Max Bolingbroke 22 Mar '08

22 Mar '08

Hi, I'm interested in working on a plugins system for the Glasgow Haskell Compiler. The idea here is to allow third parties to add more capabilities to the compiler in a way that doesn't involve messing around with modifying GHC itself. Potential use cases are: * Allow Haskell code to be selectively run on GPUs * Idiosyncratic application-specific optimization passes * And whatever clever ideas the community comes up with! This project has previously been proposed as an Microsoft Research internship project (http://hackage.haskell.org/trac/ghc/wiki/Internships).I have a preliminary wiki page with details at http://hackage.haskell.org/trac/ghc/wiki/Plugins I'd particularly like to get feedback from the list on: * Other design goals people would like to see * Improvements to the proposed (very half-baked!) user interface * Other hooks people think they might like to have into the compiler * Interested mentors. Simon PJ has indicated he would be interested in mentoring this, but there might be other projects that need him more? This project would satisfy a dependency that Manuel mentioned in http://groups.google.com/group/fa.haskell/msg/3ca260fb075a901e to implement an "array DSL" for GPUs in Haskell. It would mean GHC taking a dependency on hs-plugins (http://www.cse.unsw.edu.au/~dons/hs-plugins/) as that's our current strategy to allow GHC to dynamically link with the plugins. A little about my experience with GHC: this year I worked on implementing comprehensive comprehensions (http://research.microsoft.com/~simonpj/papers/list-comp/index.htm) as my final year undergraduate project, supervised by Simon PJ. I have subsequently implemented a few other patches, adding some core-level optimizations / bug fixes (some of which are pending review). Thanks in advance for your comments! Max

3 2

AMQP framing layer: design help requested.
by Paul Johnson 21 Mar '08

21 Mar '08

I'm trying to implement the AMQP framing layer. This is the bottom layer of the protocol that packs and unpacks data in lazy ByteStrings. I'm using the Binary package with its "Get" and "Put" monads to do the unpacking, and that works well. But I've run into a problem and I can't find an elegant solution. I'm wondering if someone can help. The following contains a simplified version of my current design. I've mapped the AMQP basic types to Haskell types. Sometimes this is a basic mapping, sometimes to something more complex. Strings have several AMQP representations, so I've created corresponding newtype declarations and instances. Some AMQP types can contain tagged types. For instance a "map" contains (key, tag, value) triples, where the tag is a single byte indicating the type of the value. I've defined the following type: data AmqpVariant = AmqpVarWord8 Word8 | AmqpVarWord16 Word16 | AmqpVarStr8 Str8 -- And so on for about 20 more types instance Binary AmqpVariant where put (AmqpVarWord8 v)= putWord8 0x01 >> putWord8 v put (AmqpVarWord16 v) = putWord8 0x02 >> putWord16be v put (AmqpVarStr8 v) = putWord8 0x03 >> put v -- And so on for about 20 more types get = do getter <- fmap (amqpGetTable !) getWord8 getter amqpGetTable :: Array Word8 (Get AmqpVariant) amqpGetTable = array (0,255) [ (0x01, fmap AmqpVarWord8 getWord8), (0x02, fmap AmqpVarWord16 getWord16be), (0x03, fmap AmqpVarStr8 get), -- And so on for about 20 more types ] This is a Brute Force and Ignorance solution, but it will probably work. But now I've come up against another type, which AMQP calls an "array". This has a single type tag at the start, followed by N items of that type. I'm wondering how to do this. One option would be to declare data AmqpArray = AmqpArrWord8 [Word8] | AmqpArrWord16 [Word16] -- and so on This effectively duplicates the AmqpVariant solution. It would work, but it feels horrible. I get the feeling that there ought to be a better way, possibly using classes or existential types. Any suggestions? Thanks, Paul.

2 2

ANN: Takusen 0.8.1
by Alistair Bayley 21 Mar '08

21 Mar '08

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Takusen-0.8.1 This is a fairly minor bugfix release. although there are some API changes. Mainly, we've re-exported a lot of the types from Database.InternalEnumerator in Database.Enumerator. This will hopefully address a common complaint that it's impossible to always write type sigs for functions doing database stuff. We've also tidied up some of the exports; there was stuff exposed that shouldn't have been. There's an outstanding bug involving datetime parameter marshaling in ODBC, which I have not had time to resolve (parameters after the datetime parameter get mangled somehow). I will be on holiday for a few weeks, so this will not be addressed by me for some time. Caveat user. The test suite highlights it, should someone else feel sufficiently motivated; I've been testing against PostgreSQL. Alistair

2 1

YOrd and ysort
by Krzysztof Skrzętnicki 20 Mar '08

20 Mar '08

The ysort function I've written for YOrd class was incredibly inefficient. Here is better one: ysort :: (YOrd a) => [a] -> [a] ysort = head . mergeAll . wrap wrap :: [a] -> [[a]] wrap xs = map (:[]) xs mergeAll :: (YOrd a) => [[a]] -> [[a]] mergeAll [] = [] mergeAll [x] = [x] mergeAll (a:b:rest) = mergeAll ((merge a b) : (mergeAll rest)) merge :: (YOrd a) => [a] -> [a] -> [a] merge [] [] = [] merge xs [] = xs merge [] xs = xs merge xs ys = let ((sm:smS),gts) = xs `ycmp` ys in smS `seq` gts `seq` sm : (merge smS gts)

1 0

ANN: The Disciplined Disciple Compiler - alpha 1
by Ben Lippmeier 20 Mar '08

20 Mar '08

Hi All, I'm pleased to announce the initial alpha release of the Disciplined Disciple Compiler (DDC). Disciple is an explicitly lazy dialect of Haskell which includes: - first class destructive update of arbitrary data. - computational effects without the need for state monads. - type directed field projections. All this and more through the magic of effect typing. More information (and download!) available from: http://www.haskell.org/haskellwiki/DDC or http://code.google.com/p/disciple DDC: more than lambdas. Onward! Ben.

7 8

Help me understand this pattern
by Justin Bailey 20 Mar '08

20 Mar '08

All, Yesterday I wrote some code I thought was very clever (even though I stole most of it) and I wonder what the pattern is. I have seen it in at least one other place, and I suspect it's well known to long-time Haskellers. The problem I wanted to solved was creating a combinator that could be defined to take any number of differently typed arguments and convert them to a more fundamental representation. To be concrete, I have a data type Expr: data Expr a = ... where a is a phantom type. I wanted users of the library (haskelldb) to be able to define functions[1] such as: -- Trim whitespace from the expression given. trim :: Expr a -> Expr String -- Pad the expression given to the correct length with the given string, if one is given. rpad :: Expr a -> Expr Int -> Maybe String -> Expr String I wanted them to be able to do this using one combinator from the library and I did not want to expose the guts of the library so they could define the functions directly in the untyped, primitive representation. That is, I did NOT want to define my combinator as: func :: String -> [PrimExpr] -> Expr a Using ideas already in haskelldb, I came up with this: data ExprNil = ExprNil data ExprCons h tl = ExprCons h tl func :: String -> (ExprNil -> ExprCons (Expr e) tl) -> Expr o arg :: (Expr a) -> (tl -> ExprCons (Expr a) tl) Using these two functions, I could define trim and rpad via composition and I did not have to expose a primitive representation or use an existentially quantified data type[2]: trim str = func "trim" $ arg str rpad str len (Just pad_str) = func "rpad" $ arg str . arg len . arg (toExpr pad_str) where toExpr :: String -> Expr String rpad str len Nothing = func "rpad" $ arg str . arg len Notice how in the second case of 'rpad', the function defined only has two arguments since no padding character was provided. With that background, I'm hoping others can tell me what this generalizes too. It's pretty clear I'm working with type-level lists, but I'm sure there is more. Is this encoding existentials? Is the (ExprCons hd tl) type really a continuation? I'm positive this is a well-known pattern and I'd really like to learn more about it (history, other uses, libraries that depend on it, etc.). Thanks in advance! Justin [1] These functions are used to generate SQL code and do not actually do the operations given. For example, trim causes the "trim" function to be applied to the column given when the SQL is actually generated. [2] Just a note that these functions are NOT in haskelldb right now - this is my own experimentation.

1 0

ANN: Network.MiniHTTP 0.2
by Adam Langley 20 Mar '08

20 Mar '08

Since many people are interested in a ByteString HTTP library, here's network-minihttp 0.2 [1]. * Has code for both clients and servers * HTTP and HTTPS support (the latter is a little shaky, but mostly works) * DNS lookups (in the client code) don't block the whole process The Haddock documentation is at: http://darcs.imperialviolet.org/minihttp-docs/index.html Half the interfaces are ill-thought out, and the rest are just as bad. However, if you send me your ideas for how it should look I'll certainly consider them. The major omission at the moment are defensive timeouts for talking to the network. However, these shouldn't be too hard. [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/network-minihttp… -- Adam Langley agl(a)imperialviolet.org http://www.imperialviolet.org

1 0

Termination of substitution
by Neil Mitchell 20 Mar '08

20 Mar '08

Hi I'm trying to show that a system of rules for manipulating Haskell expressions is terminating. The rules can be applied in any order, to any subexpression - and there is a problem if there is any possible infinite sequence. The rule that is giving me particular problems is: (\v -> x) y => x[v/y] (I realise this rule may duplicate the computation of y, but that is not relevant for this purpose.) In particular, given the expression (\x -> x x) (\x -> x x) we can keep applying this rule infinitely. However, I don't believe this expression is type safe in Haskell. Are any such expressions that would cause this to non-terminate not type safe? What are the necessary conditions for this to be safe? Does GHC perform lambda reduction, probably by introducing a let binding? Does the combination of reducing lambdas and creating let bindings give similar problems, particularly if bindings are inlined? I'm wondering if this rule is genuinely unsafe in Haskell. If it is, why isn't it an issue in real simplifiers. If it isn't, what makes it safe. Thanks for any help, Neil

4 5