October 2010 - Haskell-Cafe

Re: Polyvariadic functions operating with a monoid
by oleg＠okmij.org 13 Oct '10

13 Oct '10

Sorry, I'm still catching up. I'm replying to first few messages. > instance Show a => Monoidable a [String] where > toMonoid a = [show a] > > main = putStrLn $ unwrap $ polyToMonoid [] True () (Just (5::Int)) > fails to compile. The error message points to the first problem: > No instances for (Monoidable Bool [a], > Monoidable () [a], > ... The presence of the type variable 'a' means that the type checker doesn't know list of what elements you want (in other words, the context is not specific enough to instantiate the type variable a). Thus, we need to explicitly tell that we wish a list of strings: > test3 = putStrLn $ unwrap $polyToMonoid ([]::[String]) True () (Just (5::Int)) Now we get a different error, which points to the real problem this time: the expression `unwrap ....' appears as an argument to putStrLn. That means that we are required to produce a String as a monoid. Yet we specified ([]::[String]) as mempty, which is unsuitable as mempty for the String monoid. If we desire the [String] monoid as the result, we need to change the context. For example, > test3 = mapM_ putStrLn $ unwrap $ > polyToMonoid ([]::[String]) True () (Just (5::Int)) > Another example that also fails to compile (but I cannot see why): > main = putStrLn $ show $ unwrap $ polyToMonoid (0::Int) (1::Int) > (2::Int) (3::Int) > No instance for (PolyVariadic Int (WMonoid m)) > arising from a use of `polyToMonoid' The error message is informative, mentioning the type variable, m. Whenever that happens, we know that we put a bounded polymorphic expression in the context that is not specific enough. We need some type annotations. In our case, the function 'show' can show values of many types. The type checker does not know that we wish an Int monoid specifically. So, we have to specialize the show function: > test4 = putStrLn $ (show :: Int -> String) $ > unwrap $ polyToMonoid (0::Int) (1::Int) (2::Int) (3::Int) At this point one may wonder if this is all worth it. There are too many annotations. Fortunately, if you are not afraid of one more extension, the annotations can be avoided. Your example would be accepted as it was written, see test3 and test4 below. > {-# LANGUAGE TypeSynonymInstances #-} > {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, TypeFamilies #-} > > module M where > > import Data.Monoid > > newtype WMonoid m = WMonoid{unwrap :: m} > > class Monoid m => Monoidable a m where > toMonoid :: a -> m > > class Monoid m => PolyVariadic m p where > polyToMonoid :: m -> p > > instance (Monoid m', m' ~ m) => PolyVariadic m (WMonoid m') where > polyToMonoid acc = WMonoid acc > > instance (Monoidable a m, PolyVariadic m r) => PolyVariadic m (a->r) where > polyToMonoid acc = \a -> polyToMonoid (acc `mappend` toMonoid a) > > instance Show a => Monoidable a String where > toMonoid = show > > instance Show a => Monoidable a [String] where > toMonoid a = [show a] > > test2 = putStrLn $ unwrap $ polyToMonoid "" True () (Just (5::Int)) > > test3 = mapM_ putStrLn $ unwrap $ polyToMonoid [] True () (Just (5::Int)) > > instance Monoid Int where > mappend = (+) > mempty = 0 > > instance Monoidable Int Int where > toMonoid = id > > test4 = putStrLn $ show $ > unwrap $ polyToMonoid (0::Int) (1::Int) (2::Int) (3::Int) P.S. Indeed, "polyToMonoid' = unwrap . polyToMonoid" does not do what one wishes to. One should regard `unwrap' as a sort of terminator of the argument list.

2 3

Windows binary for latest darcs head
by Aaron Gray 12 Oct '10

12 Oct '10

Does anyone have a Windows binary for the latest GHC darcs head or at least October 8th they could send me. Many thanks in advance, Aaron

2 1

Protocol buffer network examples
by Mads Lindstrøm 12 Oct '10

12 Oct '10

Hi I am trying to read and write delimited messages[3] using protocol-buffers [1,2] over a socket. I have managed to write delimited messages and I was looking for examples of reading delimited messages. Maybe somebody has an example of reading delimited messages from a socket? The Haskell protocol-buffer[1] package mostly uses bytestrings, but I need to read from a socket. Of cause, I can use the bytestring package to read X number of bytes from a socket-handle. But it is impossible to know what X is, before you start parsing the message, as even integers are variable length in protocol buffers. Hope somebody can help, Mads Lindstrøm [1] http://hackage.haskell.org/package/protocol-buffers [2] http://code.google.com/p/protobuf/ [3] Delimited messages is a protocol buffers technique, where one writes the size of the message before the actual message: http://code.google.com/apis/protocolbuffers/docs/techniques.html#streaming

1 0

Re: RealFrac methods for Double and Float
by Antoine Latter 12 Oct '10

12 Oct '10

On Tue, Oct 12, 2010 at 10:02 AM, Tyson Whitehead <twhitehead(a)gmail.com> wrote: > On October 11, 2010 15:12:12 Daniel Fischer wrote: >> GHC's new code generator does some incredible stuff with the code for >> Float's RealFrac instance, properFraction has become about _seven times_ >> faster, floor and ceiling about _thirteen times_ and round about _10.5 >> times_ (values for my box, the exact numbers will differ, but the tendency >> will be the same). > > Out of curiosity, by new code generator, are you meaning just the stock GHC 7 > code path or are you meaning the new now available but disabled by default > unless you use some flag (which I forget right now) code generation path. > > Cheers! -Tyson > When I did the GHC 7 timings I simply ran the shell script provided in the linked tarball - no funny business. Antoine

2 1

Data.Judy
by Tom Doris 12 Oct '10

12 Oct '10

Hi, Are there any plans to extent the current Data.Judy package to include bindings to JudySL and JudyHS? There's a standalone binding to JudySL by Andrew Choi that is usable but it would of course be better to have the functionality in the Data.Judy package proper. Thanks Tom

2 1

Haskellers.com survey
by Michael Snoyman 12 Oct '10

12 Oct '10

Hey all, Guessing popular consensus based on what people write on the mailing list is not exactly statistically sound. So instead, I've put up some of our open questions- along with some other questions I've wanted to ask- in a survey. If you are interested in the future of Haskellers, I encourage you to fill it out. https://spreadsheets.google.com/viewform?formkey=dG8tcVhBdzRSS1lkdVV6U281em… Michael

1 0

Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)
by John Lato 12 Oct '10

12 Oct '10

> > From: Michael Snoyman <michael(a)snoyman.com> > > Also, now 10 random profiles will be displayed on the homepage. Only > "verified users" will be displayed here. I'm also considering adding a > new status as well: real picture, so that only people with real images > (not cartoons, not identicons) can show up on the homepage. I think > this might give a more professional feel. Thoughts? I agree that it would be nice to use only real pictures, however I wouldn't want to leave out those who choose not to use any image at all. What about a site policy that user images must be real pictures (if they exist), and violations can be flagged/blocked? Although, I don't know how this would interact with using OpenID, which appears to be most of the users currently displaying an identicon. John

4 4

Re: [Haskell-cafe] pointers for EDSL design
by Dominique Devriese 12 Oct '10

12 Oct '10

2010/10/12 <oleg(a)okmij.org>: >> An alternative approach to model sharing at the object level is the >> technique I use for modelling context-free grammars in my PADL 2011 >> paper "Explicitly Recursive Grammar Combinators"... Using ideas from >> the Multirec generic programming library and some recent Haskell type >> system extensions (most importantly GADTs and type families), you can >> do this in a well-typed way for sets of mutually recursive >> object-level expressions. > > I guess you are using what I call `the initial embedding' of an object > language. Somehow I prefer the final embedding. No. In the library, I use both embedding styles for different purposes, but what I was referring to here (the construction of production rules) is actually implemented using what you call a typed tagless-final embedding. I see the technique as an encoding of *recursion* in a typed tagless final object language in such a way that the recursion is observable in the host language. Suppose you have the following (logically inconsistent ;)) code (in Haskell notation): term1 :: Int term1 = if term2 then 1 else 2 term2 :: Bool term2 = term1 == 2 and you want to model it in the typed tagless final encoding of simply typed lambda calculus from the examples in your online typed tagless final lecture notes [1] extended with implicit arbitrary recursion. Then you could do data Term1 data Term2 data TermDomain ix where Term1 :: TermDomain Term1 Term2 :: TermDomain Term2 data family TermVal ix newtype instance TermVal Term1 = TV1 {unTV1 :: Int} newtype instance TermVal Term2 = TV2 {unTV2 :: Bool} class ExtraSymantics repr where if_ :: repr h Bool -> repr h a -> repr h a -> repr h a eq_int :: repr h Int -> repr h Int -> repr h Bool class RecSymantics repr phi | repr -> phi where ref :: phi ix -> repr h (TermVal ix) terms :: (Functor (repr h), Symantics repr, ExtraSymantics repr, RecSymantics repr TermDomain) => TermDomain ix -> repr h (TermVal ix) terms Term1 = fmap TV1 $ if_ (fmap unTV2 (ref Term2)) (int 1) (int 2) terms Term2 = fmap TV2 $ eq_int (fmap unTV1 (ref Term1)) (int 2) In this way, the embedding models the object language recursion in such a way that the recursion remains observable in the host language because you can implement it the way you want in your RecSymantics instance. Possible needs for this observable recursion could be that you want to do some form of recursion depth-bounded evaluation or some form of static analysis or whatever... Such modifications are fundamentally impossible if you model object language recursion naively using direct host language recursion. For my parsing library, I need these techniques to get a good view on the recursion in the grammar. This allows me perform grammar transformations and analysis. Dominique Footnotes: [1] http://okmij.org/ftp/tagless-final/course/#infin1

1 0

Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
by Brandon Moore 12 Oct '10

12 Oct '10

While I can see your point about potentially introducing new security holes, and producing much less trusted code, I feel having tidy, pure libraries that we can all integrate into our Haskell is a benefit that far outweighs this. Especially when we have nice things like the type system, which can be used to alleviate many of the security worries. I agree in general, for code like servers and file formats, but I worry in particular about cryptographic primitives. Some side channel attacks seem to call for a very low-level language, to make it easier to verify that e.g. execution time and the memory access pattern does not depend on the key.

3 2

[Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocol implementation
by Vincent Hanquez 12 Oct '10

12 Oct '10

Hi haskellers, I'ld like to announce the tls package [1][2], which is a native implementation of the TLS protocol, client and server. It's currently mostly supporting SSL3, TLS1.0 and TLS1.1. It's got *lots* of rough edges, and a bunch of unsupported features, but it's humming along, and at each iteration it's becoming more tighly secure and featureful. I would recommend against using this implementation in a production system just yet, or in an aggressive environment either (specially for the server side); I don't think it should necessary fail, but it's still an early implementation with probable API changes on the way. [1] http://github.com/vincenthz/hs-tls [2] http://hackage.haskell.org/package/tls -- Vincent Hanquez

12 34