- Haskell-Cafe - Haskell.org

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 15 Dec '16

15 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 15 Dec '16

15 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 14 Dec '16

14 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 14 Dec '16

14 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 14 Dec '16

14 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

Gitter Haskell Community
by Ben Spencer 13 Dec '16

13 Dec '16

Hello all, We have a small group of Haskellers over in our Gitter community chat. If you're inclined, come check us out at https://gitter.im/haskell-chat/Lobby. We have about 40 Haskell enthusiasts so far! Why Gitter you might ask? Gitter was designed for open communities. It's free for unlimited users and you get full access to your chat history. And you only need your Github account to sign up. Plus if we generate enough activity, Gitter will feature Haskell as a suggested community! Best, Ben

10 10

Supporting Haskell.org in 2016
by Adam Foltzer 13 Dec '16

13 Dec '16

Dear Haskellers, A great deal of core infrastructure, including HaskellWiki, Hackage, Hoogle, and build infrastructure for GHC are hosted and managed with the help of donations to haskell.org, from you, the Haskell community. As many of us are in tax jurisdictions where December 31st is a deadline for charitable giving, I’d like to remind you that donations to support these activities are tax-deductible. You can donate online right now through the donate button on the wiki: https://wiki.haskell.org/Donate_to_Haskell.org. Mailing information for checks is also on that page. New for this year, individual donations may be made directly via Paypal rather than the clickandpledge service, and Haskell.org is also can now accept donations through employers via Benevity using the unique ID 475236502. This year we had a successful first Summer of Haskell, offering 8 stipends of $5,500 to students making valuable contributions to our shared tooling and infrastructure such as ghc, ghcjs, and hackage, and engaging them in what we hope becomes a long succession of contributions to open source software. The exciting results are available at https://mail.haskell.org/ pipermail/haskell-cafe/2016-December/125702.html; this work is only made possible by your generous support, and that of the sponsors listed at https://summer.haskell.org/. We also have continued improving our infrastructure, using committee funds to help the development of a new performance tracker for ghc, with the aim of opening this up to a broader range of projects as well. With your support, we hope to continue these activities and more in 2017. Best wishes, Adam Foltzer on behalf of the Haskell.org committee

1 0

A Procedural-Functional Language (WIP)
by Rik Howard 13 Dec '16

13 Dec '16

Dear Haskell Cafe Subscribers on the recommendation of someone for whom I have great respect, I have just subscribed to this list, it having been suggested as being a good place for me to get feedback regarding a project that I have been working on. I am humbled by the level of discussion and it feels to be a very bold step for me to request anybody's time for my words. The linked document is a four-page work-in-progress summary: the length being stipulated, potential novelty being the other main requirement. Given the requirements, the summary necessarily glosses over some details and is not yet, I fear, completely correct. The conclusion is, more or less, the one at which I am aiming; the properties are, more or less, the ones that are needed. http://www.dcs.bbk.ac.uk/~rik/gallery/work-in-progress/document.pdf The work arises from an investigation into functional programming syntax and semantics. The novelty seems to be there but there is too a question as to whether it is simply a gimmick. I try to suggest that it is not but, by that stage, there have been many assumptions so it is hard to be sure whether the suggestion is valid. If anyone has any comments, questions or suggestions, they would be gratefully received. Yours sincerely Rik Howard

15 36