December 2016 - Haskell-Cafe

Re: [Haskell-cafe] Absolutely confused with error/exception handling
by Saurabh Nanda 18 Dec '16

18 Dec '16

My recommendation is to catch the exception in IO first, before it is lifted into the ActionCtxT. If your business logic is decoupled from the web framework (as it should be) then it should be easy enough to do this. I'm trying to write a "global" error handler which logs unhandled errors to Airbrake along with information from the request object (domain, URL, params, cookies, etc). I understand that I can make this part of my app monad, but if I don't understand why I'm unable to catch errors in MonadIO I'm bound to get stuck again, or implement it incorrectly (for example, what are the resource leaks that were being referred to?) Also what if a particular handler is not in my app monad? How do I prevent someone from accidentally adding a handler without the airbrake integration? -- Saurabh.

2 1

regression in memory usage between 6.10 and 7.x?
by Ben Franksen 17 Dec '16

17 Dec '16

In the functional pearl "A Play on Regular Expressions" by Sebastian Fischer, Frank Huch, and Thomas Wilke, the authors explain how to implement a Glushkov automaton in a very elegant way. They claim that when they compile their code with ghc-6.10.4 and with -O2 optimization they get: """ 1 MB total memory in use ... Total time 0.06s (0.21s elapsed) """ for a program that matches stdin against the equivalent (in grep -E syntax) of ^(a?){500}a{500}$ When I try their code on my machine with ghc-7.10.3 (and also -O2) I get: """ ben@sarun[1]: .../play/regexfp > ghc Reg.hs -O2 -o re [1 of 1] Compiling Main ( Reg.hs, Reg.o ) Linking re ... ben@sarun[1]: .../play/regexfp > ./re 500 +RTS -s True ... 155 MB total memory in use ... Total time 1.031s ( 1.037s elapsed) """ The details of the RTS report furthermore tell me that GC is responsible for more than 80% of the runtime. Now, I certainly have a different machine and perhaps OS than the authors of the paper, but that can't explain a factor of 16 in runtime and of 150 in memory use. I have double and triple checked my code for possible mistakes. I /do/ get the expected results (same as in the paper). I tried different numbers and found n total memory in use / MB 100 8 200 28 500 169 1000 698 which shows that memory consumtion is roughly quadratic in n. I tried heap profiling but that tells me only that all the allocation is done by the function 'shift', which I already knew (or rather guessed). I also tried several compiler versions: 7.0.4, 7.10.3, 7.4.2, 7.6.3, 8.0.1. They all result in similar performance. The ghc version the authors used is 6.10.4 and I don't have a package for that compatible to my distribution. Any hint as to where these differences might come from are appreciated. I have attached the program for reference. Cheers Ben -- "Make it so they have to reboot after every typo." ― Scott Adams

2 2

Absolutely confused with error/exception handling
by Saurabh Nanda 17 Dec '16

17 Dec '16

Hi, What started as a simple exercise of writing an Airbrake integration for Spock, has turned into a day of reading about errors, Control.Exception, MonadThrow, MonadCatch, sync, asynchronous, etc. Even after all that reading I haven't been able to find answers to the following -- * What exactly is done by the "error" function? How does one "trap" those errors and react to it? Can "catch" trap those errors? What is "e" in the case of errors raised by "error"? * How is "error" different from "throw" and "throwIO" (in the Control.Exception package, I believe) * What does MonadThrow and MonadCatch bring to the table? My understanding is that they are bringing a unified API to representing short-circuitable computations based on the inherently short-circuitable value of the host monad. Eg throwM in Maybe just results in a Nothing. throwM in List results in [] Therefore, in most of the cases throwM is not really using the error machinery built into the Haskell language (what said machinery is, is the very first question that I still don't completely understand) All of this might be obvious, and I might have just reached a mind-block after hours of reading. Help would be really appreciated :) -- Saurabh.

4 12

Fwd: Your Assembly at 33C3
by Profpatsch 16 Dec '16

16 Dec '16

We will organize a “Functional Hot-Pot” at 33C3, where friends of functional languages, Haskellistas, Lambdroids and Scalafists can share their experience and have a good time. https://events.ccc.de/congress/2016/wiki/Assembly:Functional_Hot-Pot If you want to maybe organize a workshop or have other ideas, don’t hesitate to contact me (this mail or DECT LBDA). -- Proudly written in Mutt with Vim on NixOS. Q: Why is this email five sentences or less? A: http://five.sentenc.es May take up to five days to read your message. If it’s urgent, call me.

1 1

Optional C dependencies / build-time feature toggles
by Tobias Dammers 14 Dec '16

14 Dec '16

Hello Cafe, I have this project here: https://sprinkles.tobiasdammers.nl/ (source on github: https://github.com/tdammers/sprinkles) and it has a bunch of runtime dependencies on C libraries. Many of them are only required for certain use cases, e.g., the libmysqlclient dependency is only relevant if you want to access MySQL database backends, libfcgi is only required for hosting as FastCGI (which isn't even the recommended first choice), etc. Still, in order to build and run Sprinkles, all the dependencies must be installed, which is of course not ideal. The pipe dream would be for those dependencies to be optional *at run time*, such that the application would test for their presence on startup, or load them dynamically when and if they're needed. However, I'm also fine with making them compile-time feature toggles, such that users can enable only the ones they need. Doing some sort of autotools-style dependency discovery would of course be cool as well (i.e., only enable mysql support if libmysqlclient is present). So the broad question is, which of these are realistic, and how would I go about it? And, regarding feature toggles, this bit in the Cabal FAQ baffles me a little: > Question: I like to let the user enable extended functionality using a > Cabal flag. Is this the right way? > > Answer: Certainly not. Since other packages can distinguish packages > only according to their name and their version, it is not a good idea > to allow different APIs for the same package version. Cumbersome as it > is you have to move extra features to a separate package. Moving the features to a separate package wouldn't really solve anything AFAICT, because I'd still have to bring them together somehow. -- Tobias Dammers - tdammers(a)gmail.com

5 4

Tracing HTTP request/response using servant-client or http-client
by Jan von Löwenstein 14 Dec '16

14 Dec '16

Hi, I wonder if there is a possibility to make servant-client or the layer below, i.e. http-client log all requests and corresponding responses into a log file. There is `managerModifyRequest :: ManagerSettings <https://hackage.haskell.org/package/http-client-0.5.4/docs/Network-HTTP-Cli…> -> Request <https://hackage.haskell.org/package/http-client-0.5.4/docs/Network-HTTP-Cli…> -> IO <https://hackage.haskell.org/package/base-4.9.0.0/docs/System-IO.html#t:IO> Request <https://hackage.haskell.org/package/http-client-0.5.4/docs/Network-HTTP-Cli…> ` ( https://github.com/snoyberg/http-client/blob/master/http-client/Network/HTT…) which would allow to build logging for requests I suppose. However I could neither find a corresponding hook for Response, nor a "batteries included"TM `logRequests = True`, `requestLogger=...` or something along those lines. Best Jan

1 1

Offline compilation with Stack/Cabal
by Jan von Löwenstein 13 Dec '16

13 Dec '16

Hi, Consider the following use case: I have to ship a Haskell application as source, bundled with its dependencies and a script that can produce the binary on a machine without internet connectivity. Is that possible with Stack or Cabal? Any pointers would be much appreciated. Ideally I would like to build each dependency package individually. That way I could cache results per Haskell package and don't need to rebuild dependencies until they actually change. Best Jan

5 8

Modelling structurally subtyped and cyclic data in type safe Haskell
by Aura Kelloniemi 13 Dec '16

13 Dec '16

Hello This is my first post to Haskell Café. I am a hobbyist programmer who has lots of experience with imperative and OO languages ranging from 80286 assembly to Ada and Ruby. Last four years I've been learning Haskell, which has been a painfully educational experience - I have a good understanding about how CPUs work, but very little understanding about maths. This is a very long post, I apologize. Now I'm trying to create a tool which automatically generates foreign function interface (FFI) imports from C and C++ to Haskell. I have written a GCC plugin which extracts all relevant (and lots of irrelevant) information from GCC's TREEs and dumps the output as JSON. It also dumps preprocessor macros which is one of the reasons this tol is being given birth. The tool is used like Shake - import Development.Familiar and write code which glues all relevant data processing and FFI generation functions together. This is also going to be a reusable library which others can use for whatever they find the data to be useful for. This could include making FFI bindings to other languages. Some code analysis tools also might find the data useful. I'm having a hard time importing this data to Haskell in a type safe way. GCC's TREEs are structured in an OO way. I have tried to find a more functional way of representing them, but so far with no luck. The JSON data is typed, and the hierarchy is exactly the same as in GCC. Below I construct a tree of the hierarchy where I list a few of possible types and very few of the fields the data types contain. For listing fields and their types I use a syntax similar to Haskell. This shortened listing should be enough for illustration: * macro: (data fields include: name :: string, tokens :: [token], etc.) * tree: all nodes have a unique ID to be able to recover the cycles among the node graph; (id :: integer) * * translation_unit: (declarations :: [top_level_declaration]) * * constant: a compile-time constant value; (type :: type) * * * complex_constant: (value :: complex) * * * integer_constant: (value :: integer) * * namespace_decl: (name :: identifier, declarations :: [top_level_declaration]) * * declaration: (name :: identifier, type :: type) * * * const_decl: One component of enum type; (value :: type) * * * function_decl: (type :: function_type, params :: [param_decl], result :: result_decl) * * * type_decl: (no additional fields) * * type: (declaration :: type_decl, name :: identifier, size :: integer_constant, alignment :: integer, qualifiers :: [qualifier], completeness :: bool) * * * array_type: (element_type :: type, element_count :: integer) * * * numeric_type: (precision :: integer, signed :: bool, min_value :: integer_constant, max_value :: integer_constant) * * * * enumeral_type: (values :: [const_decl]) * * * function_type: (param_types :: [type], result_type :: type) * * * pointer_type: (referred_type :: type) * * * record_type: struct (C or C++)/union; (base_types :: [(type, access_info)], fields :: [field_decl or const_decl or type_decl], methods :: [method_decl]) * reference: Any node may be replaced by a reference. They can be forward or backward references. (referred_id :: integer) As you may see, tree nodes form many many cycles together. Subclasses sometimes provide stronger invariants for their fields than the parent classes. For example all declarations are associated with a type and for function_decl nodes this type is always a function_type. Now to my question. How to represent this in Haskell. Because of the enormous amount of fields per tree node, I certainly need to use records. -- Haskell follows: data BaseTree = BaseTree { id :: Int, ... ... } data BaseDecl = BaseDecl { baseTree :: BaseTree, name :: Identifier, declType :: Type, ... } data ConstDecl = ConstDecl { baseDecl :: BaseDecl, value :: ConstValue } data ConstValue = ComplexConst Complex | IntegerConst Integer data TypeDecl = TypeDecl { baseDecl :: BaseDecl } But... What shall I do about the heterogenous lists which many nodes contain. I wish I don't need to make myriards of ADTs for them, like: data AnyTopLevelDecl = ATLDConst ConstDecl | ATLDFunction FunctionDecl | ATLDNamespace NamespaceDecl | ATLDType TypeDecl -- ... data StructFieldDecl = SFDConst ConstDecl | SFDField FieldDecl | SFDType TypeDecl And so forth, basicly each heterogenous list gets its own ADT, because there is often variance in which node types can appear in the lists. I could use one big ADT like AnyDecl. However, to me it would feel like a bad design, if my types allowed RecordType nodes to reference NamespaceDecls, and therefore I don't want to pack all nodes into one type, unless I could use some type parameters or constraints to restrict the possible values the ADT could take. At first I thought that the following could solve my problem: data SomeDecl a = SomeDecl where SomeConst :: ConstDecl -> SomeDecl ConstDecl SomeField :: FieldDecl ->SomeDecl FieldDecl SomeFunction :: FunctionDecl -> SomeDecl FunctionDecl SomeType :: TypeDecl -> SomeDecl TypeDecl -- and then I would use type classes like this class TopLevelDecl decl where -- No methods needed instance TopLevelDecl ConstDecl instance TopLevelDecl FunctionDecl instance TopLevelDecl TypeDecl -- And then I could write functions like this: handleTopLevelDecl :: TopLevelDecl d => SomeDecl d -> Whatever handleTopLevelDecl (FunctionDecl f) = -- ... -- and I'd list all cases which have a TopLevelDecl instance, but not -- those which don't have. I also thought that my data types could look like -- this: data NamespaceDecl where NamespaceDecl :: { baseTree :: BaseTree, forall a. TopLevelDecl a => declarations :: [a] } Obviously this does not work, because type classes are open, and even though GHC prevents me from calling handleTopLevelDecl with (SOmeDecl FieldDecl), it still complains if I don't define an equation for it, because in some other module somebody might make a TopLevelDecl instance for FieldDecl. Now I would like to know if there is a way to solve my problem in an elegant way, e.g. by using type families. My second question is how to resolve the cyclicity of the node graph. I don't want to tie the knot, because I want to be able to manipulate the graph. Maps are one option, yes: data AnyNode = (list all possible nodes) type Id = Int type NodeIdMap = Map Id AnyNode -- Then my data types refer to other nodes like this: data FunctionDecl = FunctionDecl { parameters :: [Id] } Now I lose all type safety. I would have to insert a run-time check to every dereference of an Id if I want to make sure that function parameter declarations don't contain StringConstants. I've also considered using STRefs. During JSON parsing I would need to populate the nodes with the node Ids they refer to and then have a separate pass which turns all Ids to typed STRefs. At least with this approach I would get all possible run-time errors straight after parsing, and not when the data is used. I'm again sorry for this long elaboration. However I think that if you consider answering me you have a pretty good understanding of my problem and also a good knowledge of my level of understanding Haskell. I would like to unlearn OO-style thinking, and I would want to find a data and type representation which feels Haskellish. However I don't want to cut down the data. I want all information to be accessible in case somebody needs it. Thank you in advance! -- Aura

4 4

Re: [Haskell-cafe] RFC: functor-classes-compat
by David Feuer 13 Dec '16

13 Dec '16

On Dec 13, 2016 4:01 AM, "Oleg Grenrus" <oleg.grenrus(a)iki.fi> wrote: Hi, continuing pushing the adoption Data.Functor.Classes, I wrote a small package `functor-classes-compat` [1]. It provides lifted (Eq1, Ord1, etc.) classes for types in `containers`, `vector` and `unordered-containers`(not for Sequence or Tree yet though). Thanks for working on this. Obviously, some of these really belong in containers. I'll try to add them today. I guess there is no way they could depend on `transformers` to provide instances in build plans with `base < 4.9`, I'm not sure when I'll have time to write patches for the actual packages myself. No, I don't think that's likely. One option might be to add these instances to transformers when compiling with older base, but I don't know if Ross Paterson will want them. Current implementations are naive, but more obviously correct. More than what?

2 3

RFC: functor-classes-compat
by Oleg Grenrus 13 Dec '16

13 Dec '16

Hi, continuing pushing the adoption Data.Functor.Classes, I wrote a small package `functor-classes-compat` [1]. It provides lifted (Eq1, Ord1, etc.) classes for types in `containers`, `vector` and `unordered-containers`(not for Sequence or Tree yet though). I guess there is no way they could depend on `transformers` to provide instances in build plans with `base < 4.9`, I'm not sure when I'll have time to write patches for the actual packages myself. Current implementations are naive, but more obviously correct. The package is not yet released on Hackage, I'll do that after the comments, which are warmly welcome! Best regards, Oleg Grenrus [1]: https://github.com/phadej/functor-classes-compat

1 0