February 2012 - Haskell-Cafe

Increase GHC stack size?
by Michael Rice 05 Feb '12

05 Feb '12

Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize -RTS' to increase it. ====================== Couldn't find much on the man or info pages. Example please, say double it (16000000) for starters. Michael

3 4

Fwd: Rewrite this imperative in FP way
by L Corbijn 05 Feb '12

05 Feb '12

---------- Forwarded message ---------- From: L Corbijn <aspergesoepje(a)gmail.com> Date: Sun, Feb 5, 2012 at 10:07 AM Subject: Re: [Haskell-cafe] Rewrite this imperative in FP way To: Haisheng Wu <freizl(a)gmail.com> On Sun, Feb 5, 2012 at 7:28 AM, Haisheng Wu <freizl(a)gmail.com> wrote: > a = [1,1,1,1] > b = [0,1,2,3] > d = [0,0,0,0] > > for i in b: > for j in c: > if (i+j)<3: > d[i+j] += a[i] > > My just work implementation in Haskell > http://hpaste.org/57452 > > Another people implementation in Haskell with Monad and it turns out complex > and very imperatively. > http://hpaste.org/57358 > > Do you have any cool solution in FP way? > > Thanks. > -Simon > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > Oops forgot to reply to the list, There are several ways to make it nicer. Without assumption on what lists a, b and c contain it can be written as d = [sum $ map (a !!) [i | i <- b, j <- c, i + j < 3, i + j == dIndex] | dIndex <- [0..3]] With the assumption that b and c are both [0..3] this can be 'improved' to d = (take 3 . map sum . tail $ inits a) ++ replicate (4 - 3) 0 This generates the first three values by the complicated expression and then adds the extra zero's by using the replicate expression. This works as the value of the i-th element of d is the sum over the first i elements in a if i < 3 and 0 otherwise. A list of lists with the first i elements is generated with 'tail $ inits a' which is then summed and restricted to length 3. An alternative for this is d = (take 3 . snd $ mapAccumL (\acc ai -> (acc + ai, acc + ai)) 0 a) ++ replicate (4 - 3) 0 Where the summation and tail generating is done in the mapAccumL function. Greetings, Lars P.S. Yes the replicate (4-3) 0 can be replaced by [0], but I wanted to explicitly include the length (4) of the expected list. P.P.S. for those of you wondering what c is, looking at the solutions in hpaste c is probably defined as c = [0..3].

1 0

Conduit experiment: Is this correct?
by Ertugrul Söylemez 04 Feb '12

04 Feb '12

Hello there, I'm trying to build a server for testing the conduit and network-conduit packages. As a contrived example the goal is to pick the first three lines from the client and send them back without the line feeds. After that, I'd like to switch to a simple echo server. This is the code: module Main where import Data.Conduit import Data.Conduit.Binary as Cb import Data.Conduit.List as Cl import Data.Conduit.Network handleClient :: Application handleClient src snk = src $$ do (Cb.lines =$= Cl.isolate 3) =$ snk snk main :: IO () main = runTCPServer (ServerSettings 4000 Nothing) handleClient I'm not sure whether it is correct to use the 'snk' sink multiple times, and intuitively I'd say that this is wrong. What would be the proper way to do this? Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/

5 7

how to print out intermediate results in a recursive function?
by Qi Qi 04 Feb '12

04 Feb '12

Hello, I have a question;how can I print out the intermediate number lists in a mergesort recursive function like the following one. merge [] ys = ys merge xs [] = xs merge (x:xs) (y:ys) = if x <= y then x : merge xs (y:ys) else y : merge (x:xs) ys mergesort [] = [] mergesort [x] = [x] mergesort xs = let (as, bs) = splitAt (length xs `quot` 2) xs in merge (mergesort as) (mergesort bs) main = do print $ mergesort [5,4,3,2,1] In the main function, it only prints out the final number list. But I'd like to print out the number lists in every recursive level. How can I do that? Thanks. -- Qi Qi

8 9

ANN: bytestring-lexing 0.4.0
by wren ng thornton 03 Feb '12

03 Feb '12

-------------------------------------------- -- bytestring-lexing 0.4.0 -------------------------------------------- The bytestring-lexing package offers efficient reading and packing of common types like Double and Integral types. -------------------------------------------- -- Changes (since 0.3.0) -------------------------------------------- * Data.ByteString.Lex.Integral: added the function readDecimal_ :: Integral a => ByteString -> a A variant of readDecimal which does not return the tail of the string, and returns 0 instead of Nothing. This is twice as fast for Int64 on 32-bit systems, but has identical performance to readDecimal for all other types and architectures. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/bytestring-lexing Darcs: http://community.haskell.org/~wren/bytestring-lexing Haddock (Darcs version): http://community.haskell.org/~wren/bytestring-lexing/dist/doc/html/bytestri… -- Live well, ~wren

2 1

Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
by wren ng thornton 03 Feb '12

03 Feb '12

On 2/3/12 6:13 AM, Gábor Lehel wrote: > The first problem is that mixing prefix and postfix function > application within the same line makes it harder to read. When you > read code to try to understand what it does, the direction you like to > go in is "here's some object, first do this to it, then do that to it, > then do this other thing to it, then this fourth thing to produce the > final result". In Haskell code with prefix application, this is easy: > you read it from right to left. In OO-style code using dots, it's even > easier: you read it from left to right. But if you mix the two, it's > much harder than either: you first have to figure out where the > sentence even begins, which is going to be somewhere in the middle, > and then every time the expression switches between prefix and > postfix, you have to figure out where to continue reading. The > algorithm your brain needs to follow is a lot branchier, so to speak. It's just as easy as reading function pointers in C :) -- Live well, ~wren

1 0

TFPIE: Trends in Functional Programming in Education 2012
by Simon Thompson 03 Feb '12

03 Feb '12

[Apologies for multiple postings, Simon.] CALL FOR PAPERS/PRESENTATIONS TFPIE 2012 International Workshop on Trends in Functional Programming in Education 2012 June 11 2012 University of St Andrews, Scotland http://www.cs.ru.nl/P.Achten/TFPIE_2012/TFPIE_2012_home.html The first International Workshop on Trends in Functional Programming in Education, TFPIE 2012, will be co-located with TFP 2012 at the University of St Andrews in Scotland. The goal of TFPIE is to gather researchers, professors, teachers, and all professionals that use or are interested in the use of functional programming in education. TFPIE aims to be a venue where novel ideas, classroom-tested ideas, and work in progress on the use of functional programming in education are discussed. The one-day workshop will foster a spirit of open discussion by having a review process for publication after the workshop. The program chairs of TFPIE 2012 will screen submissions to ensure that all presentations are within scope and are of interest to participants. Potential presenters are invited to submit an extended abstract (4-6 pages) or an article (up to 16 pages). The authors of all accepted presentations will have their preprints and their slides made available on the workshop's website/wiki. Any visitors to the TFPIE 2012 website/wiki will be able to add comments. This includes presenters who may respond to comments and questions as well as provide pointers to improvements and follow-up work. After the workshop, the program committee will review, using prevailing academic standards, the articles accepted for presentation to select the best for publication in Electronic Proceedings in Theoretical Computer Science (EPTCS). Articles rejected for presentation and all extended abstracts will not be formally reviewed by the PC. TOPICS OF INTEREST TFPIE 2012 welcomes submissions describing practical techniques used in the classroom, tools used and/or developed, and any creative use of functional programming (FP) to aid education in or outside Computer Science. Topics of interest include, but are not limited to: FP and beginning CS students FP in Artificial Intelligence FP in Robotics FP and Music Advanced FP for undergraduates FP in graduate education Engaging students in research using FP FP in Programming Languages FP in the high school curriculum FP as a stepping stone to other CS topics FP and Philosophy If you are not sure if your work is appropriate for TFPIE 2012, please contact the PC chairs by e-mail at: tfpie2012(a)cs.ru.nl . Program Committee Peter Achten, Radboud University Nijmegen Jost Berthold, University of Copenhagen Marc Feeley, University of Montreal Ralf Hinze, University of Oxford Shriram Krishnamurthi, Brown University Michel Mauny, ENSTA Paris Tech James McKinna, UK Marco T. Morazan, Seton Hall University Rinus Plasmeijer, Radboud University Nijmegen Simon Thompson, University of Kent Important Dates May 20 submission of abstract or article May 25 notification of acceptance June 11 TFPIE July 6 submission of formal paper September 10 notification of acceptance October 1 camera-ready paper Venue The University of St Andrews is Scotland's first university and the third oldest in the English-speaking world, founded in 1413. Over six centuries it has established a reputation as one of Europe's leading and most distinctive centers for teaching and research. St Andrews is situated on the east coast of Fife, Scotland, UK. The town is approximately 50 miles north-east of Edinburgh, 14 miles south-east of Dundee, 78 miles south of Aberdeen, and 82 miles east of Glasgow making it easily accessible by any means of transportation. Help on traveling to St Andrews can be found at: http://www.st-andrews.ac.uk/visiting/GettingtoStAndrews/ . Questions? If you have any questions, do not hesitate to contact us at: tfpie2012(a)cs.ru.nl . Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson(a)kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt

1 0

Again, version conflicting problem with cabal-install
by Magicloud Magiclouds 03 Feb '12

03 Feb '12

Hello, As I recalled, ghc works in staticly link mode. So after one library is compiled, all its build dependencies are useless. Lost, changed, wheresoever, it does not matter. Then why the problem of version conflicting exists? By version conflicting I mean like following. This way, A is not installable by cabal. A needs B 0.1 A needs C 0.1 B needs C0.2 -- 竹密岂妨流水过山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.

3 6

Some thoughts on Type-Directed Name Resolution
by Steve Horne 03 Feb '12

03 Feb '12

There's a proposal at the moment to add support for TDNR to Haskell - to leverage "the power of the dot" (e.g. for intellisense). http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResoluti… I approve of the goal, but I'd like to suggest a different approach. My basic idea is stolen from Bertrand Meyer (Object-Oriented Software Construction, second edition). Basically, a class *is* both a module and a type. Quote... Classes as modules Object orientation is primarily an architectural technique: its major effect is on the modular structure of software systems. The key role here is again played by classes. A class describes not just a type of objects but also a modular unit. In a pure object-oriented approach: Classes should be the only modules. By the logic of equivalence relations, we can conclude that a type *is* a module. Only I'd adapt that a little. In C++, the following operators can all be used to access the "module" for some type or value... * :: Scope resolution * . Member dereference * -> Member dereference via a pointer * .* Member-pointer dereference * ->* Member-pointer dereference via a pointer In C++, a type and an instance each have their own modules. A (smart) pointer has its own module, separate from the module for the type it points to. And member-pointers exist because sometimes there's a need to reference a member without knowing or (yet) caring which instance. We already have member pointers - the functions that map an instance to the field value. It would make some sense if these could be placed in a module associated with the type (not the instance). When an instance is created of a type, that can effectively (without run-time overhead) create a new module associated with the new instance. This will contain the same field-access functions, but with the instance parameter already curried in. So there's no real need for any new meaning of the . operator - it's just access to names within a module. And there's no need for a new mechanism for accessing fields - only for a way to place them in that module scope, and a little sugar that gives us the same field-access function but with the instance parameter already curried in. Once we have these modules containing compiler-generated field-access functions, though, it makes some sense to allow additional functions (and perhaps types) to be added within that types module explicitly by the programmer. It may also make sense to allow functions to be explicitly defined which will be added to the instance-modules and support the prefix-instance-parameter sugar. Finally, as with C++, when dealing with IORef and similar, it make make sense to have a separate -> operator (spelled differently, of course). Or it could use the standard dot. C++ and D disagree in this (in C++, the smart pointer has its own module separate from the pointed-at instance - in D, there is no -> or equivalent). As an aside, Ada has already gone through a related transition. The original Ada 83 had variant records, but no "true classes". In Ada 95, "tagged types" were added which were like variant records, but which supported inheritance and run-time dispatch. The discriminant is replaced by a "tag" which is presumably implemented as a virtual table pointer. However, functions and procedures weren't members. The typical call of a "method" would be... packagename.procedure_name ( instance_arg, other_args ); Ada 2005 added some workarounds to allow conventional OOP call notation. See section 1.3 of the Ada 2005 rationale for details. However, it all feels a bit kludgy. In particular, the procedures and functions still aren't members - there are just some special rules for when they can be used as if they were. I've not actually used Ada 2005, but I'd bet some confusion can result from that. Personally, I think Meyer was at least partly right - if types (and instances) are modules, the kludge-factor is much lower. C++ actually doesn't get this quite right IMO (you can access static class members through the instance objects, for example, not just through the classes), but C++ classes *do* act mostly like modules and that is a very useful trait - particularly within the declarative sublanguage (templates etc).

6 13

Cabal-1.10.1.0 and bytestring-0.9.2.1 hackage problem.
by Alan Pogrebinschi 03 Feb '12

03 Feb '12

That Cabal-1.10.1.0 bug seems to be back, now with bytestring-0.9.2.1 just uploaded to hackage. Same workaround as last time works (or maybe its time to upgrade...). For more info see: http://www.haskell.org/pipermail/haskell-cafe/2011-August/094883.html Thanks, Alan

3 2