- Haskell-Cafe - Haskell.org

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

Eta-expansion destroys memoization?
by Brent Yorgey 12 Oct '10

12 Oct '10

Hi all, See below for this message from one of my students which has me stumped. Just when you think you understand Haskell... ;) I've cc'ed him on this message; please include him on any replies as I don't think he is subscribed to -cafe. -Brent ----- Forwarded message from Yue Wang <yulewang(a)gmail.com> ----- From: Yue Wang <yulewang(a)gmail.com> Date: Tue, 5 Oct 2010 21:23:57 -0400 To: Brent Yorgey <byorgey(a)seas.upenn.edu> Subject: store evaluated values Hi, Anthony (or Brent): Last time (in Anthony's TA office hour) we talked about how to store evaluated values in the program for later used. I googled for a while and wrote some code. But I still encountered two problems. Can you take a look? Thanks. First, let's write the naive fib function: naive_fib 0 = 0 naive_fib 1 = 1 naive_fib n = trace(show(n)) naive_fib (n - 1) + naive_fib (n - 2) this works good except it tries to calculate the same expression many times. So when we evaluate it ghci will show the following: *Main> naive_fib 5 5 4 3 2 2 3 2 5 Then there is a clever way to do that on haskell wiki: fib = ((map fib' [0 ..]) !!) where fib' 0 = 0 fib' 1 = 1 fib' n =trace(show(n)) fib (n - 1) + fib (n - 2) When we evaluate the same expression we can see it does not evaluate the redundant expression over and over: *Main> fib 5 5 4 3 2 5 The source code seems to be easy to read, but I don't think I understand that. For me I think if I change the first line from fib = ((map fib' [0 ..]) !!) to fib x = ((map fib' [0 ..]) !!) x It should do the same thing since I think the previous version is just an abbreviation for the second one. But After I change that, *Main> fib 5 5 4 3 2 2 3 2 5 So why does the x here matters?

11 11

RealFrac methods for Double and Float
by Daniel Fischer 11 Oct '10

11 Oct '10

Greetings, I have put together a package to test possible implementations of the RealFrac methods for Double and Float (base-2 IEEE754) and uploaded a .tar.gz bundle to http://hackage.haskell.org/trac/ghc/ticket/2271 . On the one hand, pure Haskell implementations, on the other hand implementations calling out to rint[f], trunc[f], floor[f] and ceil[f] from math.h. Both ways go via Integer by default, with a specialised faster implementation for Int (and narrower types, but those RULES haven't yet been written) enabled by a rewrite rule. Overall, the pure Haskell implementations don't fare badly on my computer. All give a speedup compared to the current implementation, for most conversions, pure Haskell is on par with or faster than the C-call (although that would probably change if the C functions were made primops). The FFI calls are significantly faster for properFraction :: Double -> (Integer, Double) and for round (except round :: Integral a => Float -> a when compiled via C, then native and FFI are on par). Sample results for the speedups against the current implementation (note: for truncate :: x -> Int, the Prelude value is fst . properFraction, not the rewritten float2Int or double2Int) are included in the tarball. I would appreciate feedback from your tests/benchmarks on other platforms, especially 64-bit platforms (mine is x86 linux, 32 bit). To run the QuickCheck tests, you need QuickCheck-2.*, to run the benchmarks, criterion. More instructions in the README. Thanks, Daniel

2 6