January 2012 - Haskell-Cafe

Please upgrade http-enumerator and/or http-conduit
by Michael Snoyman 17 Jan '12

17 Jan '12

Hi all, Thanks to Felipe for catching this issue[1]. Both http-enumerator and http-conduit will not properly reject invalid certificates. I've released updated versions of both packages: http-enumerator-0.7.2.4 http-conduit-1.1.2.2 All users are recommended to upgrade. Michael [1] https://github.com/snoyberg/http-conduit/pull/6

1 0

Pruned Sparks in Original Strategies
by Burak Ekici 17 Jan '12

17 Jan '12

Dear List, I am trying to parallelize some number of codes with using Haskell's original and second generation strategies in order to be able to compare them. As far as I understood, in original strategies, ROOT garbage collection mechanism is used which does not allow any spark to be pruned. Since, they do not return any information back to its caller. (a type of void reference making fizzling of a spark impossible, is returned), However, in most of my measurements, spraks are being pruned. I wonder the reasons why this incident occurs? Do you have any idea? Many thanks, Burak.

1 0

__GLASGOW_HASKELL__ for GHC 7.4
by Eugene Kirpichov 17 Jan '12

17 Jan '12

Hi, I'm fixing a build error in a package that depends on the RTS API, which changed in 7.4, using #if __GLASGOW_HASKELL__ >= 740. However, build log shows that __GLASGOW_HASKELL__ is still 704, not 740 as I'd expect. Is this a bug? -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/

2 2

Re: [Haskell-cafe] decoupling type classes
by Yin Wang 17 Jan '12

17 Jan '12

On Sat, Jan 14, 2012 at 2:38 PM, Dominique Devriese <dominique.devriese(a)cs.kuleuven.be> wrote: >> I may or may not have thought about it. Maybe you can give an example >> of parametric instances where there could be problems, so that I can >> figure out whether my system works on the example or not. > > The typical example would be > > instance Eq a => Eq [a] where > [] == [] = True > (a : as) == (b : bs) = a == b && as == bs > _ == _ = False It can handle this case, although it doesn't handle it as a parametric instance. I suspect that we don't need the concept of "parameter instances" at all. We just searches for instances recursively at the call site: 1. If "g" has an implicit parameter "f", search for values which matches the name and instantiated type in the current scope. 2. If a value is found, use it as the argument. 3. Check if the value is a function with implicit parameters, if so, search for values that matches the name and type of the implicit parameters. 4. Do this recursively until no more arguments contain implicit parameters. > This coupling you talk about is not actually there for instance > arguments. Instance arguments are perfectly usable without records. > There is some special support for automatically constructing record > projections with instance arguments though. Cool. So it seems to be close to what I had in mind. > I am not sure about the exact workings of your system, but I want to > point out that alternative choices can be made about the workings of > inferencing and resolving type-class instances such that local > instances can be allowed. For example, in Agda, we do not infer > instance arguments and we give an error in case of ambiguity, but > because of this, we can allow local instances... Certainly it should report error when there are ambiguities, but sometimes it should report an error even there is only one value that matches the name and type. For example, foo x = let overload bar (x:Int) = x + 1 in \() -> bar x baz = in foo (1::Int) Even if we have only one definition of "bar" in the program, we should not resolve it to the definition of "bar" inside foo. Because that "bar" is not visible at the call site "foo (1::int)". We should report an error in this case. Think of "bar" as a "typed dynamically scoped variable" helps to justify this decision.

2 3

fixity declaration in GHCi
by Takayuki Muranushi 17 Jan '12

17 Jan '12

Hello everyone, while I'm playing with fixity declaration in GHCi, I found a strange behavior. Can anyone explain this? Is this actually an expected behavior, or is it a glitch? ---------------------------------------------------------------- $ ghci GHCi, version 7.0.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude> minus --(1) <interactive>:1:1: Not in scope: `minus' Prelude> let minus x y = x-y; infixl 6 `minus` --(2) Prelude> 10^5 `minus` 2 --(3) 1000 Prelude> let infixl 6 `minus` --(4) <interactive>:1:14: The fixity declaration for `minus' lacks an accompanying binding Prelude> let subtract x y = x-y --(5) Prelude> 10^5 `subtract` 2 --(6) 1000 Prelude> let f x y = x-y; infixl 6 `f` in 10^5 `f` 2 --(7) 99998 Prelude> ---------------------------------------------------------------- (1) suggests that `minus` is not defined here. in (2), I try to define `minus` with precedence level 6. However, (3) suggests that precedence level of `minus` is stronger than ^ . (4) suggests that you cannot redefine fixity here. (5)(6) is consistent with Haskell 98 report section 4.4.2; "Any operator lacking a fixity declaration is assumed to be infixl 9." in (7), precedence level is set as expected. So, what is happening in (3)? Where did the fixity declaration in (2) went? Best, -- MURANUSHI Takayuki The Hakubi Center, Kyoto University : http://www.hakubi.kyoto-u.ac.jp/

1 0

Network.Browser and Network.TLS
by Myles C. Maxfield 17 Jan '12

17 Jan '12

Hello! I am interested in extending the Network.HTTP code in the HTTP package to support HTTPS via TLS. A clear candidate is to use the Network.TLS module in the TLS library (because its TLS logic is written in pure Haskell, rather than any of the FFI libraries like Network.Curl or the OpenSSL package). It's simple enough to provide an implementation of the Network.Stream.Stream typeclass around a TLSCtx, and this works for the Network.HTTP.Stream functions. However, I am interested in using the functionality in the Network.Browser module. This module uses the Network.HTTP.HandleStream interface, which is implemented directly on top of the Handle datatype and the Network.BufferType.BufferOp functions. HandleStreams seem to be for allowing the user to pull out an arbitrary data type out of an HTTP stream, not for doing any stream processing the way TLS does. As far as I can tell, the current typeclass system does not allow a TLSCtx to piggypack off of a HandleStream. My assumption is that this interface is used for speed so the user doesn't have to convert some canonical type into the type that he/she desires in client code. TLS, however, must use a specific type to decode the bytes that it pulls out of the stream. I don't think it's reasonable to try to modify the TLS library to decode bytes from an arbitrary type. Decoding necessarily needs byte-level access to its input (and therefore output) streams in a manner extremely similar to the functions that ByteString provides. Perhaps I'm wrong about this, but the conclusion I've reached is that it doesn't make sense for TLS to use an arbitrary typeclass because the interface it requires is so similar to the existing ByteString datatype. If an application wants a specific type out of a TLS stream, it must necessarily convert the type in software. Any speed that might be gained by pulling your native type out of a network connection will be dwarfed anyway by the cost of decryption. The Network.Stream functions allow this by using String type for all data transfers (which is counterintuitive for binary data transfers). An implementation of Network.Stream.Stream using TLS would convert TLS's output ByteString into a String (possibly by doing something like ((map (toEnum . fromIntegral)) . unpack) which doesn't make a whole lot of sense and is fairly wasteful). A client program might even convert it back to a ByteString, so the client program must have knowledge about how the bytes are packed into the String. Network.Browser only seems to have one function which isn't simply a state accessor/mutator: 'request'. This function gives the connection a type of HStream ty => HandleStream ty. As stated before, the HandleStream directly uses the Handle type. This means that, as far as I can tell, there is no way to fit TLS into the Network.Browser module as it stands because the types don't allow for it. Supporting TLS in Network.Browser would have to change the type of 'request' and therefore break every program out there which uses the Network.Browser module. It would be possible to create something like a 'requestHTTPS' function which returns a different type, but this is quite inelegant - there should be one function that inspects the scheme of the URI it is handed. I am left with the conclusion that it is impossible to support TLS in Network.Browser without breaking many Haskell programs. It is obviously possible to fork the HTTP library, but I'd like to improve the state of the existing libraries. Likewise, it is possible to create a new module that supports HTTPS but has different typed functions and lots of code duplication with Network.Browser, but that is quite inelegant. I suppose this is mostly directed at the maintainers of the HTTP and TLS libraries, Sigbjorn Finne and Vincent Hanquez, but I'd be greatful for your input on what I can do to contribute to the Haskell community regarding Network.Browser and Network.TLS. Perhaps I should just use the Network.HTTP.Enumerator module and not deal with Network.Browser? Maybe I'm going about this in entirely the wrong way. Thanks, Myles C. Maxfield

4 3

Happy holidays Haskell
by R J 17 Jan '12

17 Jan '12

hey Haskell I didn't believe this at all until I started http://www.news13wise.com

1 0

Haskell Summers of Code retrospective (updated for 2011)
by Gwern Branwen 16 Jan '12

16 Jan '12

The Wheel turns, and months come and pass, leaving blog posts that fade into 404s; a wind rose in Mountain View, whispering of the coming Winter... Tonight I sat down and finally looked into the 2011 SoCs to see how they turned out and judge them according to my whimsically arbitrary and subjective standards: http://www.gwern.net/Haskell%20Summer%20of%20Code#results-1 They turned out pretty much as I predicted - but then I *would* say that, wouldn't I? (Also submitted to /r/haskell for those who swing that way: http://www.reddit.com/r/haskell/comments/n82ln/summer_of_code_2011_retrospe… ) -- gwern http://www.gwern.net

3 2

ICFP 2012 Call for papers
by Wouter Swierstra 16 Jan '12

16 Jan '12

===================================================================== ICFP 2012: International Conference on Functional Programming Copenhagen, Denmark, September 9 - 15, 2012 http://www.icfpconference.org/icfp2012 ===================================================================== Important Dates ~~~~~~~~~~~~~~~ Submissions due: Monday Mar 12, 2012 14:00 UTC Author response: Monday May 07, 2012 14:00 UTC - May 9 14:00 UTC Notification: Monday May 28, 2012 Final copy due: Monday Jul 02, 2012 Scope ~~~~~ ICFP 2012 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects, concurrency, or parallelism. Topics of interest include (but are not limited to): * Language Design: concurrency and distribution; modules; components and composition; metaprogramming; interoperability; type systems; relations to imperative, object-oriented, or logic programming * Implementation: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; memory management; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components, or low-level machine resources * Software-Development Techniques: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling * Foundations: formal semantics; lambda calculus; rewriting; type theory; monads; continuations; control; state; effects; program verification; dependent types * Analysis and Transformation: control-flow; data-flow; abstract interpretation; partial evaluation; program calculation * Applications and Domain-Specific Languages: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed-systems and web programming; hardware design; databases; XML processing; scientific and numerical computing; graphical user interfaces; multimedia programming; scripting; system administration; security * Education: teaching introductory programming; parallel programming; mathematical proof; algebra * Functional Pearls: elegant, instructive, and fun essays on functional programming * Experience Reports: short papers that provide evidence that functional programming really works or describe obstacles that have kept it from working If you are concerned about the appropriateness of some topic, do not hesitate to contact the program chair. Abbreviated instructions for authors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * By March 12 2012, 14:00 UTC, submit a full paper of at most 12 pages (6 pages for an Experience Report), including bibliography and figures. The deadlines will be strictly enforced and papers exceeding the page limits will be summarily rejected. * Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. * Each submission must adhere to SIGPLAN's republication policy, as explained on the web at http://www.acm.org/sigplan/republicationpolicy.htm * Authors of resubmitted (but previously rejected) papers have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the program chair will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. Overall, a submission will be evaluated according to its relevance, correctness, significance, originality, and clarity. It should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. Functional Pearls and Experience Reports are separate categories of papers that need not report original research results and must be marked as such at the time of submission. Detailed guidelines on both categories are on the conference web site. Proceedings will be published by ACM Press. Authors of accepted submissions are expected to transfer the copyright to the ACM. Presentations will be videotaped and released online if the presenter consents. Formatting: Submissions must be in PDF format printable in black and white on US Letter sized paper and interpretable by Ghostscript. If this requirement is a hardship, make contact with the program chair at least one week before the deadline. Papers must adhere to the standard ACM conference format: two columns, nine-point font on a ten-point baseline, with columns 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter of 2pc (0.33in). A suitable document template for LaTeX is available: http://www.acm.org/sigs/sigplan/authorInformation.htm Submission: Submissions will be accepted only online via the ICFP website. Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Author response: Authors will have a 48-hour period, starting at 14:00 UTC on Monday May 7th 2012, to read reviews and respond to them. Special Journal Issue: There will be a special issue of the Journal of Functional Programming with papers from ICFP 2012. The program committee will invite the authors of select accepted papers to submit a journal version to this issue. Conference Chair: Peter Thiemann, University of Freiburg Program Chair: Robby Findler, Northwestern University Program Committee: Andreas Rossberg, Google Andrew Tolmach, Portland State University Brigitte Pientka, McGill University Colin Runciman, University of York Eijiro Sumii, Tohoku University Jan Midtgaard, Aarhus University John Hughes, Chalmers University of Technology and Quviq AB Lars Birkedal, IT University of Copenhagen Manuel Fähndrich, Microsoft Research Mariangiola Dezani-Ciancaglini, University of Turin Matthias Blume, Google R. Kent Dybvig, Cisco and Indiana University Sam Tobin-Hochstadt, Northeastern University Satnam Singh, Google Research Simon Marlow, Microsoft Research Zena M. Ariola, University of Oregon

1 0

Second CfP --- 75 Years of the Lambda Calculus
by Conor McBride 16 Jan '12

16 Jan '12

[posted on behalf of Patricia Johann] [Please note that the submission deadline is 27 January. Flyer attached below. -patty] International Workshop on 75 Years of Lambda-Calculus University of St Andrews, Scotland 15th June, 2012 Call for papers http://msp.cis.strath.ac.uk/lambda2012 Sponsored by Scottish Informatics & Computer Science Alliance (SICSA) Overview -------- In 1936, Alonzo Church?s foundational 'An unsolvable problem of elementary number theory' introduced the Lambda-calculus which, with Turing machines, now underpins contemporary theoretical and practical Computer Science. To celebrate the 75th anniversary of the publication of this seminal work, papers are invited for presentation at a one day International Workshop, to be held in St Andrews on 15th June 2012, immediately following the International Symposium on Trends in Functional Programming (TFP). Topics ------ Church's life & work Origins/history Computability Programming language design & implementation Logic, proof & reasoning Guest Speakers -------------- Henk Barendregt, University of Nijmegen Chris Hankin, Imperial College Roger Hindley, University of Swansea Fairouz Kamareddine, Heriot-Watt University Workshop Chairs --------------- Greg Michaelson, Heriot-Watt University Patricia Johann, University of Strathclyde Programme Committee ------------------- Robert Atkey, University of Strathclyde Dan Dougherty, WPI Maribel Fernandez, Kings College London Philip Scott, University of Ottawa Dates (2012) ------------ 27th January: submission 2nd March: notification of acceptance for Workshop 18th May: deadline for draft proceedings 15th June: Workshop 31st August: deadline for HOSC special issue 30th November: notification of acceptance for HOSC Submissions ----------- Submissions will be 'light touch' refereed for relevance before the Workshop, and will appear in the draft proceedings, with full refereeing thereafter for publication in a special issue of Higher Order and Symbolic Computation. Submissions should be of 16 pages maximum length in the Springer format from http://cs.au.dk/~hosc/ Submission ---------- https://www.easychair.org/conferences/?conf=75ylc Registration ------------ There will be an attendance charge of around ?50 for refreshments, lunch, and proceedings. There will be no charge for PhD students from SICSA affiliated Universities. Registration will be through TFP: http://www.cs.st-andrews.ac.uk/~kh/TFP2012/TFP_2012/Home.html

1 0