- Haskell-Cafe - Haskell.org

A new case for the pointed functor class
by roconnor＠theorem.ca 02 Dec '15

02 Dec '15

>From <http://r6research.livejournal.com/28338.html>: There has been some debate for some time as to whether there should be a superclass for Applicative with just the pure function should exist: -- Natural law: -- fmap f . pure = pure . f class Functor f => Pointed f where pure :: a -> f a The charge laid against this class is that there are no laws for this single function beyond the single law that is naturally implied. Compare this to a more reasonable class -- Natural laws: -- distRight . right . fmap f = fmap (right f) . distRight -- distRight . left f = fmap (left f) . distRight -- -- Other laws: -- 1. either absurd (fmap Right) = distRight :: Either Void (f a) -> f (Either Void a) -- 2. fmap assocL . distRight . right distRight . assocR = distRight :: Either (Either a b) (f c) -> f (Either (Either a b) c) -- where -- assocL :: Either a (Either b c) -> Either (Either a b) c -- assocL (Left a) = Left (Left a) -- assocL (Right (Left a)) = Left (Right a) -- assocL (Right (Right a)) = Right a -- assocR :: Either (Either a b) c -> Either a (Either b c) -- assocR (Left (Left a)) = Left a -- assocR (Left (Right a)) = Right (Left a) -- assocR (Right a) = Right (Right a) class Functor f => StrongSum f where distRight :: Either a (f b) -> f (Either a b) distLeft :: Either (f a) b -> f (Either a b) distLeft = fmap switch . distRight . switch where switch :: Either a b -> Either b a switch = Right ||| Left StrongSum is a honest class with two additional real laws in addition to its natural laws. No one would object to creating and using such a class. What if I told you that Pointed and StrongSum are in fact the same class? class Functor f => Pointed f where pure :: a -> f a pure = fmap (id ||| absurd) . distRight . Left distRight : Either a (f b) -> f (Either a b) distRight = either (fmap Left . pure) (fmap Right) Theorem 1. If we define pure, then the distRight automatically satisfies the 2 required laws. Proof. Law 1: either absurd (fmap Right) = { extensionality of absurd } either (fmap Left . pure) (fmap Right) = { definition in terms of pure } distRight :: Either Void (f a) -> f (Either Void a) Law 2: fmap assocL . either (fmap Left . pure) (fmap Right) . right (either (fmap Left . pure) (fmap Right)) . assocR = either (fmap Left . pure) (fmap Right) case 1: Right x fmap assocL . either (fmap Left . pure) (fmap Right) . right (either (fmap Left . pure) (fmap Right)) . assocR $ Right x = fmap assocL . either (fmap Left . pure) (fmap Right) . right (either (fmap Left . pure) (fmap Right)) $ Right (Right x) = fmap assocL . either (fmap Left . pure) (fmap Right) $ Right (either (fmap Left . pure) (fmap Right) (Right x)) = fmap assocL . either (fmap Left . pure) (fmap Right) $ Right (fmap Right x) = fmap assocL $ fmap Right (fmap Right x) = fmap (assocL . Right . Right) x = fmap Right x = either (fmap Left . pure) (fmap Right) $ Right x case 2: Left (Right x) fmap assocL . either (fmap Left . pure) (fmap Right) . right (either (fmap Left . pure) (fmap Right)) . assocR $ Left (Right x) = fmap assocL . either (fmap Left . pure) (fmap Right) . right (either (fmap Left . pure) (fmap Right)) $ Right (Left x) = fmap assocL . either (fmap Left . pure) (fmap Right) $ Right (either (fmap Left . pure) (fmap Right) (Left x)) = fmap assocL . either (fmap Left . pure) (fmap Right) $ Right (fmap Left (pure x)) = fmap assocL $ fmap Right (fmap Left (pure x)) = fmap (assocL . Right . Left) (pure x) = fmap (Left . Right) (pure x) = fmap Left . fmap Right . pure $ x = fmap Left . pure . Right $ x = fmap Left . pure $ Right x = either (fmap Left . pure) (fmap Right) $ Left (Right x) case 3: Left (Left x) fmap assocL . either (fmap Left . pure) (fmap Right) . right (either (fmap Left . pure) (fmap Right)) . assocR $ Left (Left x) = fmap assocL . either (fmap Left . pure) (fmap Right) . right (either (fmap Left . pure) (fmap Right)) $ Left x = fmap assocL . either (fmap Left . pure) (fmap Right) $ Left x = fmap assocL . fmap Left . pure $ x = fmap (assocL . Left) . pure $ x = fmap (Left . Left) . pure $ x = fmap Left . fmap Left . pure $ x = fmap Left . pure . Left $ x = fmap Left . pure $ Left x = either (fmap Left . pure) (fmap Right) $ Left (Left x) Theorem 2. If we define pure, then pure = fmap (id ||| absurd) . distRight . Left where distRight = either (fmap Left . pure) (fmap Right) Proof. fmap (id ||| absurd) . distRight . Left = fmap (id ||| absurd) . either (fmap Left . pure) (fmap Right) . Left = fmap (id ||| absurd) . fmap Left . pure = fmap ((id ||| absurd) . Left) . pure = fmap id . pure = pure Theorem 3. If we define distRight such that distRight satisfies its two laws then distRight = either (fmap Left . pure) (fmap Right) where pure = fmap (id ||| absurd) . distRight . Left. Proof. either (fmap Left . fmap (id ||| absurd) . distRight . Left) (fmap Right) = distRight case 1: Left x either (fmap Left . fmap (id ||| absurd) . distRight . Left) (fmap Right) $ Left x = fmap Left . fmap (id ||| absurd) . distRight $ Left x = fmap (Left . (id ||| absurd)) $ distRight (Left x) = fmap (Left ||| (Left . absurd)) $ distRight (Left x) = fmap (Left ||| absurd) $ distRight (Left x) = { extensionality of absurd } fmap (Left ||| Right) $ distRight (Left x) = fmap id $ distRight (Left x) = distRight (Left x) case 2: Right x either (fmap Left . fmap (id ||| absurd) . distRight . Left) (fmap Right) $ Right x = fmap Right x = fmap (left absurd . Right) x = fmap (left absurd) $ fmap Right x = fmap (left absurd) . either absurd (fmap Right) $ Right x = { Law 1 for distRight } fmap (left absurd) . distRight $ Right x = { Natural law for distRight } distRight . left absurd $ Right x = distRight $ Right x Interestingly we only ever used the first law for distRight. By composing these proofs together we should be able to show that the second law for distRight holds whenever the first law does. In conclusion we have seen that the StrongSum class and the Pointed class are equivalent classes. The pure function contains the heart of what a law abiding distRight function is, such that whenever we have a law abiding distRight function it can be written in terms of pure and every instance of pure yields a law abiding distRight function. Given that I think people would welcome a StrongSum class, it only makes sense to equally welcome the Pointed class. -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

2 1

Monadic function fails as Nothing in Maybe context but as Exception in Either context.
by Jeffrey Brown 01 Dec '15

01 Dec '15

I've written a monadic function which in a Maybe context produces a Nothing when it fails (as intended), but in an Either context produces an Exception rather than a Left. Here's a tiny demonstration. "tinyGraph" below has one Node, 0, with the label "dog". If I try to change the label at Node 0 to "cat", it works. If I try to change the label at Node 1 to "cat", it fails, because Node 1 is not in the graph. type MyGraph = Gr String String tinyGraph = mkGraph [(0, "dog")] [] :: MyGraph maybeSucceed = replaceStringAtNodeM tinyGraph 0 "cat" :: Maybe MyGraph -- == Just (mkGraph [(0,"cat")] []) maybeFail = replaceStringAtNodeM tinyGraph 1 "cat" :: Maybe MyGraph -- == Nothing eitherSucceed = replaceStringAtNodeM tinyGraph 0 "cat" :: Either String MyGraph -- == Right (mkGraph [(0,"cat")] []) eitherFail = replaceStringAtNodeM tinyGraph 1 "cat" :: Either String MyGraph -- *** Exception: Node not in Graph Here's the code: import Data.Graph.Inductive -- FGL, the Functional Graph Library gelemM :: (Monad m) => MyGraph -> Node -> m () gelemM g n = if gelem n g -- FGL's gelem function returns then return () -- True if the node is in the graph else fail "Node not in Graph" -- False otherwise replaceStringAtNode :: MyGraph -> Node -> String -> MyGraph replaceStringAtNode g n e = let (Just (a,b,c,d),g') = match n g in (a,b,e,d) & g' replaceStringAtNodeM :: (Monad m) => MyGraph -> Node -> String -> m MyGraph replaceStringAtNodeM g n s = do gelemM g n return $ replaceStringAtNode g n s -- if evaluated, the pattern match in replaceStringAtNode must succeed, -- because gelemM catches the case where n is not in the graph [1] https://github.com/JeffreyBenjaminBrown/digraphs-with-text/blob/master/test… -- Jeffrey Benjamin Brown

5 10

[ANN] clang-pure-0.1.0.0: Pure C++ code analysis
by Patrick Chilton 01 Dec '15

01 Dec '15

Hi everyone, I've been working on a pure binding to libclang that lets you easily analyze any code that the Clang compiler understands. Github: https://github.com/chpatrick/clang-pure Hackage: http://hackage.haskell.org/package/clang-pure Haddock: http://chpatrick.github.io/clang-pure/ libclang documentation: http://clang.llvm.org/doxygen/group__CINDEX.html A short example that prints out the type of every function in a header file (very useful for binding generation): main = do idx <- createIndex tu <- parseTranslationUnit idx "foo.h" [] let root = translationUnitCursor tu funDecs = root ^.. cosmosOf cursorChildrenF . filtered (\c -> cursorKind c == FunctionDecl) . folding (\c -> fmap (\t -> ( cursorSpelling c, typeSpelling t )) (cursorType c)) for_ funDecs $ \(f, t) -> putStrLn $ BS.unpack f ++ " :: " ++ BS.unpack t Or to find the number of gotos: gotoCount = lengthOf (cosmosOf cursorChildrenF . filtered (\c -> cursorKind c == GotoStmt)) root (This uses lens, but the library itself only has one optional lens-style function). Please refer to libclang's good documentation for an explanation of the functions. The only thing to keep in mind is that functions clang_foo are renamed to just foo, functions clang_getBar are renamed to just bar, and types CXBaz are renamed to just Baz in the Haskell bindings. Under the hood, a reference counting system ensures that the C objects are freed at the right time and in the right order, which allows the public API to be simple and pure. The bindings are not yet complete, so if you find something missing please make an issue or better yet send a pull request. :) Patrick

1 0

Month in Haskell Mode November 2015
by Gracjan Polak 01 Dec '15

01 Dec '15

Welcome Haskell Mode users, Haskell Mode progress report for November 2015 (online version <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-November…> ). For previous issue see October 2015 <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-October-…> . Go to Reddit discussion <https://www.reddit.com/r/haskell/comments/3uz7jl/month_in_haskell_mode_nove…> . <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-November…>What is Haskell Mode? Haskell Mode is an umbrella project for multiple Emacs tools for efficient Haskell development. Haskell Mode is an open source project developed by a group of volunteers. For more information see https://github.com/haskell/haskell-mode. <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-November…>Important developments The bug that everybody was waiting for <https://github.com/haskell/haskell-mode/issues/962> was fixed! No more 'Illegal token' in indentation. Rejoice! <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-November…>Coming release In the beginning of December we plan to tag new stable release of haskell-mode with current state of the repo (plus possible bugfixes). <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-November…>Competitive projects Haskell editor landscape is growing and there are compelling propositions all over the place: - Atom IDE-Haskell <https://atom.io/packages/ide-haskell> - Haskell Vim IDE <https://github.com/begriffs/haskell-vim-now> - Leksah - Haskell IDE in Haskell <http://leksah.org/> - Haskell for Mac <http://haskellformac.com/> There is an idea turning into reality that there should be a common infrastructure powering all of the above. It is brewing in Haskell IDE Engine <https://github.com/haskell/haskell-ide-engine> repo. <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-November…>Cruft removal, reminder Last month we declared that we plan to remove some cruft. Note that SCC functions got salvaged and now they are fully functional part of haskell-mode! Killing list for December: - Remove haskell-bot.el <https://github.com/haskell/haskell-mode/pull/960> - Remove horizontal whitespace based smart indentation mode haskell-simple-indent <https://github.com/haskell/haskell-mode/pull/958> - Remove Unicode input method <https://github.com/haskell/haskell-mode/pull/939> - Remove haskell-checkers.el <https://github.com/haskell/haskell-mode/pull/959> <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-November…>Current project focus Current project focus is to lower entry barrier for newcomers by defining bite-sized tasks. Get 50 'well-defined-tasks' done as by the metric: https://github.com/haskell/haskell-mode/issues?q=is%3Aissue+label%3Awell-de… A 'well-defined-task' is a category of tasks that have the field cleared for them, questions already sorted out and detailed information how to get them done. So you can just sit, search for 'well-defined-task' label and enjoy the coding! The point is to lower the entry barrier for new users, new issue reporters and advanced programmers but Emacs lisp beginners to contribute to the project. Current status: 14 well-defined-tasks closed <https://github.com/haskell/haskell-mode/issues?q=is%3Aissue+label%3Awell-de…> plus 13 more open <https://github.com/haskell/haskell-mode/issues?q=is%3Aissue+label%3Awell-de…> . If only you can help with reaching our targets please do so! <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-November…>Issues closed in November - Repl hanging #447 <https://github.com/haskell/haskell-mode/issues/447> - On opening a file, haskell-doc opens several files defined in import section #742 <https://github.com/haskell/haskell-mode/issues/742> - Indentation has been spoiled #782 <https://github.com/haskell/haskell-mode/issues/782> - Refactor load-or-reload #807 <https://github.com/haskell/haskell-mode/issues/807> - Make import sorting/aligning optional #914 <https://github.com/haskell/haskell-mode/issues/914> - Remove possibility of 'Illegal token' from haskell-indentation #962 <https://github.com/haskell/haskell-mode/issues/962> - Can't edit a buffer while resolving merge conflict because Invalid Token error. #969 <https://github.com/haskell/haskell-mode/issues/969> - C pragma and Illegal token: else #970 <https://github.com/haskell/haskell-mode/issues/970> - Please do not make haskell-mode non-useful without ghc-mod #974 <https://github.com/haskell/haskell-mode/issues/974> - haskell-process-load-file: cabal test-suite wants to inject deps into library #979 <https://github.com/haskell/haskell-mode/issues/979> - Parsing failure with type-level lists #982 <https://github.com/haskell/haskell-mode/issues/982> - Stop blocking me from typing my code #985 <https://github.com/haskell/haskell-mode/issues/985> - haskell-process-do-type truncates types too aggressively #988 <https://github.com/haskell/haskell-mode/issues/988> - Code duplication between haskell-process-do-type, haskell-process-insert-type #989 <https://github.com/haskell/haskell-mode/issues/989> - Issues trying to use local version of a package in a layer #993 <https://github.com/haskell/haskell-mode/issues/993> - Emacs haskell-mode: how to send PART of file to repl? #1002 <https://github.com/haskell/haskell-mode/issues/1002> - haskell-process-load-file error (wrong-type-argument number-or-marker-p nil) when code has an error #1004 <https://github.com/haskell/haskell-mode/issues/1004> <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-November…>Pull requests merged in November - Add haskell-font-lock-tests.el. #957 <https://github.com/haskell/haskell-mode/pull/957> - [Doc] Add stack related configuration for compilation #971 <https://github.com/haskell/haskell-mode/pull/971> - Extract hoogle/hayoo code into haskell-hoogle.el and tidy up #973 <https://github.com/haskell/haskell-mode/pull/973> - Move some docs from wiki to manual #976 <https://github.com/haskell/haskell-mode/pull/976> - Don't spuriously modify tags-table-list's global value #978 <https://github.com/haskell/haskell-mode/pull/978> - Add an additional trigger for pragma suggestions #983 <https://github.com/haskell/haskell-mode/pull/983> - Add hayoo choice as part of hoogle url. #984 <https://github.com/haskell/haskell-mode/pull/984> - Clean up SCC code #986 <https://github.com/haskell/haskell-mode/pull/986> - Truncate multi-line messages less aggressively #990 <https://github.com/haskell/haskell-mode/pull/990> - Spelling #991 <https://github.com/haskell/haskell-mode/pull/991> - Use haskell-process-load-file, not -load-or-reload #992 <https://github.com/haskell/haskell-mode/pull/992> - Add RET, TAB and BACKTAB tests #994 <https://github.com/haskell/haskell-mode/pull/994> - Add case for haskell-debug-parse-module regex to parse #995 <https://github.com/haskell/haskell-mode/pull/995> - Remove duplicate filename in Makefile #996 <https://github.com/haskell/haskell-mode/pull/996> - Remove haskell-indentation-parse-error #997 <https://github.com/haskell/haskell-mode/pull/997> - Fix markup typo in README.md #999 <https://github.com/haskell/haskell-mode/pull/999> - Remove haskell-indentation-parse-error, fixup #1001 <https://github.com/haskell/haskell-mode/pull/1001> - Do not sort imports twice #1003 <https://github.com/haskell/haskell-mode/pull/1003> <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-November…>Contributors active in November Cody Goodman, Daniel Bergey, Gabor Greif, Gracjan Polak, Moritz Kiefer, Sibi Prabakaran, Steve Purcell, Thien-Thi Nguyen <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-November…> Contributing Haskell Mode needs volunteers like any other open source project. For more information see: https://github.com/haskell/haskell-mode/wiki Also drop by our IRC channel: #haskell-emacs at irc.freenode.net. Thanks!

1 0

[ANN] dejafu-0.2.0.0: Overloadable primitives for testable, potentially non-deterministic, concurrency.
by Michael Walker 01 Dec '15

01 Dec '15

Hi cafe, I am happy to announce a new release of Déjà Fu, my library for testing concurrent Haskell programs! Things have advanced significantly since the paper I presented at the Haskell Symposium this year, both in terms of performance and functionality. Git: https://github.com/barrucadu/dejafu Hackage: https://hackage.haskell.org/package/dejafu-0.2.0.0 ## What is it? Déjà Fu is a library for developing and testing concurrent Haskell programs, it provides a typeclass-abstraction over GHC's regular concurrency API, allowing the concrete implementation to be swapped out. Why do we need this? Well, concurrency is really hard to get right. Empirical studies have found that many real-world concurrency bugs can be exhibited with small test cases using as few as two threads: so it’s not just big concurrent programs that are hard, small ones are too. We as programmers just don’t seem to have a very good intuition for traditional threads-and-shared-memory-style concurrency. The typical approach to testing concurrent programs is to just run them lots of times, but that doesn’t provide any hard coverage guarantees, and then we need to wonder: how many runs do we need? Fortunately, there has been a lot of research into testing concurrency in the past several years. Systematic concurrency testing is an approach where the source of nondeterminism, the actual scheduler, is swapped out for one under the control of the testing framework. This allows possible schedules to be systematically explored, giving real coverage guarantees for our tests. This is a library implementing systematic concurrency testing. It provides two typeclasses, MonadConc to abstract over much of Control.Concurrent and related modules, and MonadSTM, to similarly abstract over Control.Monad.STM. For examples, see the test suite and the async-dejafu source: - https://github.com/barrucadu/dejafu/tree/master/dejafu-tests - https://github.com/barrucadu/dejafu/tree/master/async-dejafu If you want to read more: - Recent technical report: http://misc.barrucadu.co.uk/pub/dejafu-techreport.pdf - Haskell Symposium paper about version 0.1.0.0: http://www.barrucadu.co.uk/publications/dejafu-hs15.pdf - A slew of things on my blog: http://www.barrucadu.co.uk/posts.html ## Changelog New stuff: - Relaxed memory: CRefs now behave just like IORefs, and testing can use one of three different memory models: sequential consistency, total store order (the default), and partial store order. - Support for 'yield'. - Integration with HUnit and tasty: https://hackage.haskell.org/package/hunit-dejafu https://hackage.haskell.org/package/tasty-dejafu - Version of the async library reimplemented to use MonadConc: https://hackage.haskell.org/package/async-dejafu - Fair bounding: which allows yield-based constructs like spinlocks to be tested without causing infinitely-long executions. - Length bounding: which allows for potentially non-terminating computations to be tested. Improvements: - Now uses partial-order reduction to cut down on the number of schedules to try, which is a *huge* improvement over just pre-emption bounding, which is what 0.1.0.0 did. - The 'autocheck' function has prettier output. ## How to use it: If you’re not making use of any IO in your code other than for concurrency, the transition to using MonadConc and MonadSTM will probably just be a textual substitution: - IO is replaced with MonadConc m => m - STM with MonadSTM m => m - *IORef with *CRef - *MVar with *CVar - *TVar with *CTVar - Most other things have the same name, and so can be replaced by just swapping imports around. If you are using other IO, you will need a gentle sprinkling of MonadIO and liftIO in your code as well. ## Is this really just a drop-in replacement for IO/STM? That’s the idea, yes. More specifically, the IO instance of MonadConc and the STM instance of MonadSTM just use the regular IO and STM functions, and so should have no noticeable change in behaviour. There are some differences which can lead to incorrect results when testing, but which should not affect code when used in an IO or STM context. Specifically: Control.Monad.Conc.Class.getNumCapabilities can lie to encourage more concurrency when testing; and Control.Exception.catch can catch exceptions from pure code, but Control.Monad.Conc.Class.catch can’t (except for the IO instance). -- Michael Walker (http://www.barrucadu.co.uk)

1 0

Fwd: Fwd: Compatibility etiquette for apps, with cabal sandboxes and `stack`
by Paolo Giarrusso 30 Nov '15

30 Nov '15

On 29 November 2015 at 20:12, Michael Orlitzky <michael(a)orlitzky.com> wrote: > On 11/29/2015 01:37 PM, Omari Norman wrote: >> >> Distribution packagers are savvy enough to use stack. > > Ignoring the question of *how* that might work, most distributions > forbid bundled dependencies because it creates a maintenance nightmare > and fills our users' machines with untraceable security vulnerabilities. But doesn't Haskell do static linking (usually) and cross-module inlining? Or are you fine with static linking as long as it's somehow tracked by the package manager, so that upgrading some-vuln-lib from 1.0 to 1.1 forces upgrading all client programs (looks quite doable at least with Debian packages)? -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/ -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/

4 4

Fwd: Fwd: Compatibility etiquette for apps, with cabal sandboxes and `stack`
by Sven Panne 30 Nov '15

30 Nov '15

[... and now to the whole list, I hate gmail's defaults... :-] ---------- Forwarded message ---------- From: Sven Panne <svenpanne(a)gmail.com> Date: 2015-11-29 21:12 GMT+01:00 Subject: Re: [Haskell-cafe] Fwd: Compatibility etiquette for apps, with cabal sandboxes and `stack` To: Imants Cekusins <imantc(a)gmail.com> 2015-11-29 20:52 GMT+01:00 Imants Cekusins <imantc(a)gmail.com>: > [...] What if the top package (in namespace) contained major version? > > E.g. Cabal_1_22 > > below packages might use minor versions - basically, whenever api changes, > change the version part of the affected package. [...] > As a developer, what should I import if my program/library works with e.g. the version range [1.20 .. 1.23]? It definitely can't be import Cabal_1_23.Foo.Bar because if it later still works with e.g. 1.24, I would have to rename all my imports. And always using the lower bound is probably too restrictive, unless I'm mistaken... In general I think it's a bad idea to spread build dependencies all over the code. Cheers, S.

3 6

make a server & connect to it - strange behavior
by Patrick Redmond 30 Nov '15

30 Nov '15

Hi Haskell Cafe, When I start a web server (http-server:Network.HTTP.Server.serverWith) on a separate thread (async:Control.Concurrent.Async.withAsync) and then try to retrieve a response from the server (HTTP:Network.Browser.*) on a threaded runtime, I see either - connection refusals or - deadlock. Before I sink time into reading the source of the packages in question, does anybody see what's wrong with the code below? Increasing the timeout to wait for the server to initialize doesn't solve the problem. Using a bound thread doesn't solve the problem. I'm compiling with options "-threaded -rtsopts -with-rtsopts=-N". Thank you for taking a look. --Patrick This test project is on github. <https://github.com/plredmond/http-server-test-hs/blob/master/src/Lib.hs> module Lib ( someFunc ) where import Control.Monad.IO.Class (liftIO) import qualified Control.Concurrent as Concurrent import qualified Control.Concurrent.Async as Async import qualified Control.Exception as Exception import qualified Data.Maybe as Maybe import qualified Network.Browser as Browser import qualified Network.HTTP as HTTP import qualified Network.HTTP.Server as Server import qualified Network.HTTP.Server.Logger as ServerL import qualified Network.HTTP.Server.Response as ServerR import qualified Network.URI as URI someFunc :: IO (Either Exception.SomeException (URI.URI, HTTP.Response String)) someFunc = do Async.withAsync (Server.serverWith config handler) $ \_ -> do Concurrent.threadDelay . round $ 2e6 Exception.try . Browser.browse . Browser.request . Browser.defaultGETRequest $ uri where uri = Maybe.fromJust . URI.parseURI $ "http://localhost:8080/" config = Server.Config ServerL.stdLogger "localhost" 8080 handler _ url req = return (ServerR.respond ServerR.OK :: Server.Response String)

1 1

Fwd: Compatibility etiquette for apps, with cabal sandboxes and `stack`
by Omari Norman 29 Nov '15

29 Nov '15

On Sun, Nov 29, 2015 at 6:54 AM, Paolo Giarrusso <p.giarrusso(a)gmail.com> wrote: > Hi all, > > IIUC, people used to spend nontrivial effort making their Haskell tools > work across a range of dependencies, and be careful about dropping support > for older ones. > Given the tools we had, this was not easy. I was never aware of any tool that substantially helped with making sure that a package remained compatible with the range of packages that was theoretically allowed by the package's .cabal file. > Do cabal sandboxes or Stack reduce that need, at least for applications?* > Or conversely, how bad is it to restrict support to users having them? I > guess I am asking about common policies, but this probably depends on > adoption of those tools. > > IMO there is really no one right answer to this question. It depends on how nice you are, or whether someone is paying you. Obviously if someone is paying you, do as she says or do what she needs. If no one is paying you, then how nice do you want to be by expending the work? Honestly I'm not very nice. I keep stuff working in the current Stackage Nightly but that's it. Maintaining compatibility with huge dependency matrices is just an enormous amount of work. In my view, someone installing an application can just use stack and Stackage.

6 10

Semi-closed handles and I/O errors: misleading documentation?
by Daniel Díaz 29 Nov '15

29 Nov '15

In the documentation for System.IO <http://hackage.haskell.org/package/base-4.8.1.0/docs/System-IO.html>, we find the following assertion: Any I/O errors encountered while a handle is semi-closed are simply discarded. also this other one: Encoding and decoding errors are always detected and reported, except during lazy I/O (hGetContents, getContents, and readFile), where a decoding error merely results in termination of the character stream, as with other I/O errors. Is this really correct, though? This SO question <http://stackoverflow.com/questions/16257037/detecting-i-o-exceptions-in-a-l…> says that exceptions found during lazy I/O are thrown from pure code, and a small experiment <http://stackoverflow.com/a/33985047/1364288> seems to confirm it. I personally prefer that behaviour, by the way. Perhaps the documentation should be updated?

1 0