- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] [Haskell] GHC is a monopoly compiler
by Tom Murphy 28 Sep '16

28 Sep '16

This is not the right mailing list for this ( https://wiki.haskell.org/Mailing_lists) ; forwarding to haskell-cafe@ Tom On Tue, Sep 27, 2016 at 7:48 AM, Tony Day <tonyday567(a)gmail.com> wrote: > I would argue that the adventure that is GHC is a natural monopoly - an > example of collaboration trumping competition. Certainly the results speak > for themselves, and I personally find it the most satisfying, the only sane > way to practice the craft of coding. So, as an enthusiastic user of a > monopolistic service (the best power to weight ratio I could find to > misquote Kmett), I would like to suggest to the community that we have a > respectful discussion on the implications of natural monopolies. > > Monopolies have their problems. They create power imbalances that need > active management to control. A community should be particularly wary of > monopolies attempting to vertically integrate up the production chain into > areas where a monopoly makes less sense. I would call the whole cabal > versus stack drama a text-book case of over-reach. Everyone agrees stack > operates at a higher level of abstraction then cabal, on top of it is > accurate. Cabal shouldn't even be allowed to compete above it's current > abstraction point. > > Haddock is another example of being blessed by ghc. It hits a corner-case > of perfection for the "I'm a hackage library" monopoly. But the outside > world of documentation, editing, rendering and conversion is invisible to > this monopolistic use case. We are forced to learn and use haddock, and, > for those of us with documentation needs outside hackage, the resultant > workflow is cruel and unusual. > > GHC is a great compiler, but should actively be discouraged from > monopolizing the associated tooling and documentation chains. There is > evidence of healthy open-source competition and significant gains to be > had, and Haskell runs the risk of missing out. > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > >

14 24

technical thoughts on stack
by Richard Eisenberg 27 Sep '16

27 Sep '16

I’ve watched the recent back-and-forth about stack with quite a bit of interest (as many of us have). The discussion inspired me to take another look at stack. Here are the results of that foray. First, a disclosure: While I have appreciated the emergence of a new build tool for Haskell, I have never much liked stack. One of my chief goals in taking another look is to understand better why I do not like it. My task: Set up a Haskell environment on a new machine (a Mac). This machine has no Haskell infrastructure on it. My approach: 1. `brew install haskell-stack`. Success. At this point, I do not have a Haskell project I wish to build. Instead, I really just want the ability to run Haskell expressions in GHCi. So I skip `stack new` and go straight to 2. `stack setup`. This succeeds, but prints out some interesting messages along the way, including > Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of 71c0a55d0a877954d9590e285c0eb861ace2d8cc > Right Nothing At the end, I am helpfully told > To use this GHC and packages outside of a project, consider using: > stack ghc, stack ghci, stack runghc, or stack exec > So I then 3. `stack ghci`. My computer’s first reaction is to say > Run from outside a project, using implicit global project config > Using resolver: lts-6.17 from implicit global project's config file: /home/rae/.stack/global-project/stack.yaml > Error parsing targets: The specified targets matched no packages. > Perhaps you need to run 'stack init'? > Warning: build failed, but optimistically launching GHCi anyway > which doesn’t make me feel all that comfortable, but then I am indeed delivered to the GHCi prompt, which works as expected. Done with GHCi, I quit. I then want to double-check which version of GHC I got, so I 4. `stack ghc --version`. This command reports > Invalid option `--version’ Grumble. It seems I can’t interact with GHC directly. ———— At this point, I am reminded why I dislike stack: **It’s optimized for a different workflow than I use.** And I think this fact (repeated by others’ experiences) is why a segment of our community has not celebrated stack as much as other segments have. We all have different workflows. From what I understand about it, stack is great for a project-based workflow. In this workflow, you are working on a Haskell project. You are happy to specify settings in .cabal and stack.yaml files. And you really want your build to work in the future and on other machines. In my experience, stack is not great with a compiler-based workflow. In this workflow, you aren’t quite as organized perhaps and do not have all your settings written. You also want the ability just to compile a file without changing any configurations. You want to be able to start GHCi with a nice set of libraries with which to experiment. I definitely like a compiler-based workflow. I’m sure that many of you prefer a project-based workflow. The great news here is that we have a choice: use stack for a project-based workflow, and don’t use it when you want a compiler-based workflow. No one needs to convince others about personal preferences. But there is one nagging issue: what do we suggest to newcomers? The downloads page right now is not serving us well. (I was legitimately scratching my head at first trying to figure out how to provision a new computer.) Sadly, I don’t see a good option presenting itself. Both potential approaches (The Haskell Toolchain vs. stack) have (in my opinion) serious shortcomings. A. The Haskell Toolchain (that is, what’s currently called the Haskell Platform Minimal) does appear to lack a “here’s what you do first” tutorial. Forgive me if I’ve missed it. It’s also right now quite hard to discover — you have to choose the oft-maligned Haskell Platform link before you are told that there is a minimal variant. B. stack sets up GHC in a way that either 1) requires a project-based workflow with a stack.yaml file or 2) issues a bunch of somewhat-scary warnings every time GHC is invoked outside of a project. Furthermore, stack prohibits direct interaction with GHC (as in `ghc --version`). There’s more good news here! Both of these problems are really easy to fix. To fix (A), someone just has to write the tutorial. To fix (B), stack just needs a new option so that `stack setup` installs a system GHC. Perhaps it would even be sufficient for `stack setup` to clearly tell the user where ghc is installed and what to add to their PATH. I also think, if readers agree with my conclusions about workflows, we should consider writing up criteria that potential users should consider when choosing what workflow to start with. We’ll need to have a tighter recommendation for those with no experience programming, but most developers should be able to recognize what workflow they prefer and choose accordingly. Of course, there’s a bit of bad news: If both (A) and (B) are fixed, then we’ll really be in a quandary about which installation procedure to put first. Perhaps we should incentivize fixing (A) and (B) by saying whichever one happens first gets to be featured first on the page? :) So: Does my characterization of workflows resonate? Have I perhaps identified part of the burning black heart of the reason behind the vitriol of late? Should we fix (A) and (B)? I’m looking forward to hearing your thoughts. Richard -=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae

23 49

Re: [Haskell-cafe] The meaning of categories constructed from HASK
by Olaf Klinke 27 Sep '16

27 Sep '16

Dear Dimitri, I've never seen arrow or slice categories in a paper on functional programming. Commutative squares are most frequently used in the definition of typeclasses, where the documentation usually reads: Instances should satisfy: f.g = h.i where f,g,h,i are some functions involved in the definition of the typeclass. Haskell can not stop you writing an instance violating the commutative square, however. Certain special arrow categories are useful, even in Haskell. For example the Eilenberg-Moore category of a monad m. Objects are arrows m a -> a and morphisms are commutative squares liftM f m a ---------> m b | | | | v v a ----------> b f Such an f is sometimes called "linear". For example, every instance of Data.Monoid comes with an arrow mconcat :: (Monoid a) => [a] -> a and commutative squares between two monoids are precisely the functions f where f mempty = mempty and f (x `mappend` y) = (f x) `mappend` (f y) I'm sure you have looked at Control.Category in package base before asking this question. The Category typeclass defined there is not capable of expressing either of your examples, because: - The hom-set of a Category must be a HASK type (although not necessarily a function type) - Each hom-set must be parametrised by two HASK types The arrow category is not expressible, because we can not forge a HASK type that somehow specifies exacltly one function. Moreover, the cummutativity of a square is not expressible, that is, there is no HASK type consisting of all functions making a certain square commute. The slice category is not expressible, for the same reason as above. There are, however, interesting instances of Control.Category where the hom-set elements are not functions. For example, one could have memoized functions between stream types. The following goes back to Dirk Pattinson and Ulrich Berger, AFAIK. Suppose i is a type of tokens such that an infinite stream of i's encodes an element of type x. Likewise, let o be a type of tokens such that an infinite stream of o's encodes an element of type y. Now consider the type Mem below. -- Run the following in ghci -XNoImplicitPrelude import Control.Category import Data.List (head,tail) -- A memoized function [i] -> [o], representing a function x -> y. -- Either requesting an input token or yielding an output token. data Mem i o = Read (i -> Mem i o) | Write o (Mem i o) instance Category Mem where id = Read (\i -> Write i id) f . g = case f of Write p f' -> Write p (f' . g) Read r -> case g of Write o g' -> (r o) . g' Read r' -> Read (\i -> f . (r' i)) -- run a memoized function. -- This is a functor from Mem to HASK. runMem :: Mem i o -> [i] -> [o] runMem f input = case f of Write o f' -> o : runMem f' input Read r -> runMem (r (head input)) (tail input) If there are only finitely many possible input tokens i, then one can replace Read (i -> Mem i o) by Read (Map i (Mem i o)) in which case the entire memoized function really is a tree. Olaf

2 1

Professor Position at University of Chile
by Éric Tanter 26 Sep '16

26 Sep '16

Full-Time Academic Position Computer Science Department, University of Chile http://www.dcc.uchile.cl <http://www.dcc.uchile.cl/> The Computer Science Department of the University of Chile (DCC) is offering a full-time permanent position to carry out research and teaching, at the undergraduate and graduate levels. The DCC is the leading Computer Science Department in Chile, and one of the most active in Latin America. It pioneered the use of Unix and the adoption of the Internet in Chile. Today, it has 22 full-time professors, 10 of which come from Argentina, Uruguay, Belgium, France, and Ireland. We carry out high-quality research, publishing frequently in the most prestigious international conferences and journals. The DCC is in charge of the undergraduate Computer Science program within the Engineering Faculty of the University of Chile, reaching a thousand students in the first year of Engineering, and taking care of the CS specialization from the third year onward for over two hundreds students. Our MSc and PhD programs attract the best students from Latin America, with currently around fifty students in each program. The DCC offers newcomers an individual office and necessary equipment, as well as a starting grant for initiating their research activities; further funding is then obtained permanently upon publications. This is usually complemented with funds from a personal research project obtained from Conicyt, the national research agency, and/or with funds from larger collaborative projects. An assistant professor can supervise students of any level and have a light administrative load. Professors in our department are expected to teach three courses per year; typically one of these courses is an elective that the professor can define according to his/her interests. The salary provided by the University is very competitive, and depends on the ranking (assistant, associate, full); it is complemented with research projects. The successful candidate should be an active researcher with a PhD in Computer Science (or about to obtain it before starting the position). We are interested in any area of Computer Science, and both junior and senior researchers are welcome to apply. The candidate will be evaluated on the basis of both research and teaching activities, impact, as well as vision for the future. Important Dates We accept applications until November 30, 2016. The expected starting date is March 1, 2017 (August 2017 at the latest). Location The DCC is located in Santiago de Chile. Santiago is the capital and largest city in Chile, with a lively cultural scene and delectable cuisine. It is located at the foothills of the Andes, with over 300 days of sun per year, and both ski slopes and the Pacific coast at a 1-hour drive. Santiago is well-connected through direct flights to major hubs in both Europe and the USA. Chile is a country with a lot to offer especially to nature lovers, with over 4,300 km of seashore and mountains, filled with stunning landscapes and national parks stretching from Patagonia to the Atacama desert. For enquiries, please contact Prof. Gonzalo Navarro at gnavarro(a)dcc.uchile.cl <mailto:gnavarro@dcc.uchile.cl>

2 1

The 13-line example in Text.Megaparsec.Expr
by Jeffrey Brown 24 Sep '16

24 Sep '16

At the bottom of the Hackage documentation for Text.Megaparsec.Expr [1] is a 13-line demonstration program. It includes no import statements. I added the ones I could deduce, which produced this: import Text.Megaparsec import Text.Megaparsec.Expr import Text.Megaparsec.Lexer (symbol,integer) parens = between (symbol "(") (symbol ")") expr = makeExprParser term table <?> "expression" term = parens expr <|> integer <?> "term" table = [ [ prefix "-" negate , prefix "+" id ] , [ postfix "++" (+1) ] , [ binary "*" (*) , binary "/" div ] , [ binary "+" (+) , binary "-" (-) ] ] binary name f = InfixL (reservedOp name >> return f) prefix name f = Prefix (reservedOp name >> return f) postfix name f = Postfix (reservedOp name >> return f) That still won't compile, because GHC does not know what reservedOp means. Does reservedOp refer to something that no longer exists, or have I just not found it? [1] https://hackage.haskell.org/package/megaparsec-4.4.0/docs/Text-Megaparsec-E… -- Jeffrey Benjamin Brown

4 8

Debugging hanging template Haskell
by Cody Goodman 24 Sep '16

24 Sep '16

Can you use the ghci debugger to do this? I tried adding a piece of template Haskell to the frames library and now compilation never terminates: https://github.com/acowley/Frames/pull/59 One compiler warning warned me of overlapping instances in relation to my ZonedTime lift instance which could totally be wrong. I have a feeling maybe the overlapping instances could be making compilation hang, but I'm not sure. I'm more looking for help on how to move forward and keep debugging this than an answer, but if you only have time for an answer I'll gladly do the reverse engineering work to teach myself. Thanks all!

2 1

Munich Haskell Meeting, 2016-09-26 @ 19:30
by Christian Neukirchen 23 Sep '16

23 Sep '16

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, September 26 at *Max-Emanuel-Brauerei* at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-sep-2016/ *Please add yourself quickly so we can get enough places.* Everybody is welcome! cu, -- Christian Neukirchen <chneukirchen(a)gmail.com> http://chneukirchen.org

1 0

Understanding fgl's gfiltermap
by J. Stutterheim 23 Sep '16

23 Sep '16

Hi all, While playing with the fgl library [1] (git rev. 71b66d6), I encountered a situation where the library behaved different from what I expected. I now wonder whether I should adjust my expectations, or whether fgl has a bug. What I want to do is filter out nodes and edges based on edge labels. For a specific edge label l, if a node has an incoming or outgoing edge l it can stay, otherwise I want to remove it from my graph. Likewise, any edge that doesn't have label l needs to be removed from my graph. I wrote a program to do this using gfiltermap, but I got the wrong graph as a result. During debugging, I found that gfiltermap behaved differently from what I would expect. Take the following program: ```haskell {-# LANGUAGE TupleSections #-} module Test where import Debug.Trace import Data.Graph.Inductive main :: IO () main = prettyPrint test test :: Gr () () test = gfiltermap (Just . traceShowId) testGraph where {- - ASCII art representation of the graph: - - 1 <-4<-- 2 - /\ -/| - \ / - \3\/_ -} testGraph = mkGraph testNodes testEdges where testNodes = map (,()) [1, 2, 3, 4] testEdges = [ (2, 4, ()) , (4, 1, ()) , (2, 3, ()) , (3, 1, ()) , (3, 2, ()) ] ``` This simple program just reconstructs the original graph, but prints the contexts in the process. When it's done, it pretty prints the resulting graph. The debug tracing + pretty printing gives the following output (in that order): ([((),3),((),4)],1,(),[]) ([((),3)],2,(),[((),3),((),4)]) ([],3,(),[]) ([],4,(),[]) 1:()->[] 2:()->[((),3),((),4)] 3:()->[((),1),((),2)] 4:()->[((),1)] The pretty-printed graph correctly shows that there is an edges going from node 4 to node 1. However, the traced output shows node 4 (last line of trace output) with no successors and no predecessors. I would expect nodes 1 and 2 to be included in that tuple as the successor and predecessor in that tuple. Note that these two representations of the same graph _are_ isomorphic. Despite the isomorphism, this makes implementing my graph filter significantly more clumsy than I would like it to be. So my question is: are my expectations from the library wrong, or is this a bug? - Jurriën [1] https://hackage.haskell.org/package/fgl

2 1

The meaning of categories constructed from HASK
by Dimitri DeFigueiredo 23 Sep '16

23 Sep '16

In category theory, there are many ways one can make new categories out of an old one. In particular, given a category C one can construct: 1. The arrows category of C: arrows in C become objects and commutative squares in C become arrows 2. The slice category of C given an object A: arrows into a distinguished object A become objects in the slice commutative triangles become arrows There are also functors going from C to these new categories (and back). Are these constructed categories useful when C = `Hask` (the category of haskell types and functions)? What do they represent in programming terms? In other words, is there intuition for what the arrows category of Hask is? What about the slice category of Hask over a specific type? Do the functors between these match some programming abstractions? Any pointers are much appreciated. Thanks, Dimitri

2 1

MPTCs and extended defaulting
by Tom Murphy 23 Sep '16

23 Sep '16

I've got a case in a library I'm working on where having -XExtendedDefaultRules with MPTCs would be very, very helpful. Is it possible? I.e., we can now write: ``` {-# LANGUAGE ExtendedDefaultRules #-} data AB = A | B Double deriving (Show) class Foo x where foo :: x -> AB instance Foo Double where foo = B main = print $ foo 5 ``` And -XExtendedDefaultRules makes sure we don't need to write "5 :: Double" If, though, I want 'Foo' to take another parameter (here, a :: [Symbol]), it falls apart: ``` {-# LANGUAGE DataKinds #-} {-# LANGUAGE ExtendedDefaultRules #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MultiParamTypeClasses #-} import GHC.TypeLits data AB = A | B Double deriving (Show) class Foo x (a :: [Symbol]) where foo :: x -> AB instance Foo Double a where foo = B main = print $ foo 5 ``` Is there a reason MPTCs can't support ExtendedDefaultRules? Thanks! Tom

2 4

PLDI 2017 call for papers
by Tobias Grosser 21 Sep '16

21 Sep '16

*Call for Contributions* ==================== 2017 ACM Conference on Programming Language Design and Implementation (PLDI) June 19-23, 2017 in Barcelona, Spain http://conf.researchr.org/home/pldi-2017 PLDI is the premier forum in the field of programming languages and programming systems research, covering the areas of design implementation, theory, applications, and performance. PLDI welcomes outstanding research which clearly advances the field and has the potential to make a lasting contribution. *Important Dates* =============== Research paper submissions due 15 Nov 2016 Author response period 26-28 Jan 2017 Author notification 13 Feb 2017 *Author Instructions* ================== http://conf.researchr.org/track/pldi-2017/pldi-2017-papers Submission site: https://pldi17.hotcrp.com/ *Organizing Committee* ==================== General Chair: Albert Cohen, INRIA, France Program Chair: Martin Vechev, ETH Zurich, Switzerland Workshops & Tutorials Chair: Aaron Smith, University of Edinburgh Publicity Chairs: Adrian Sampson, Cornell, USA Tobias Grosser, ETH Zurich, Switzerland http://conf.researchr.org/committee/pldi-2017/pldi-2017-organizing-committee -- Tobias Grosser

1 0

Standard package file format
by Harendra Kumar 20 Sep '16

20 Sep '16

I am starting a new thread for the package file format related discussion. >From a developer's perspective, the major benefit of a standard and widely adopted format and is that people can utilize their knowledge acquired from elsewhere, they do not have to go through and learn differently looking and incomplete documentation of different tools. The benefit of a common config specification is that developers can choose tools freely without worrying about learning the same concepts presented in different ways. Multiple formats flying around also create a psychological impression of complexity in the ecosystem for newcomers. If we have consistency there are better chances of attracting more people to the language ecosystem. I gather the following from the discussion till now: * We have cabal, YAML and TOML as potential candidates for a common package format which can additionally incorporate the concept of snapshots/package collections and potentially more extensions useful across build tools. * cabal has the benefit of incumbency and backward compatibility, it has shortcomings which are being addressed but it is still a format which is very specific to Haskell ecosystem. It is not a standard and not going to become one. We have to always deal with it ourselves and everyone coming to Haskell will have to learn it. * YAML (http://yaml.org/spec/1.2/spec.html) is standard and popular. A significant chunk of developer community is already familiar with it. It is being used by stack and by hpack as an alternative to cabal format. The complaint against it is that the specification/implementation is overly complex. * TOML (https://github.com/toml-lang/toml) is promising, simpler than YAML and is being used by a few important projects but is still evolving and is not completely stable. On a first glance it looks pretty simple and a lot of other tools use a similar config format. It is aiming to become a standard and aiming for a wider adoption. As a next step we can perhaps do an hpack like experiment using the TOML format. That way we will have some experience with that as well and get to know if there are any potential problems expressing the existing cabal files. More thoughts, opinions on the topic will help create a better understanding about it. -harendra

25 69

implement SOAP-based standard
by Olaf Klinke 18 Sep '16

18 Sep '16

Dear Haskellers, I am considering implementing the OPC XML DA standard [1] in Haskell. OPC XML DA is based on SOAP and is used for communicating with servers controlling hardware such as power plants. Currently the only open implementation known to me is PyOPC [2], which is based on an outdated Python libraries. However, Python seems not the nicest language for writing code that is devoid of bugs showing at runtime only. The OPC XML DA standard comes with a WSDL document (600 lines). There is a wsdl package on hackage, but it is incomplete. Can anyone share experience in implementing a webservice specified as WSDL? Actually, the client side would be enough for my purposes. That is, compose well-formed messages and parse the responses. Thanks, Olaf [1] https://opcfoundation.org/developer-tools/specifications-classic/xml-data-a… [2] https://libraries.io/pypi/PyOPC

2 1

New maintainer for HsOpenSSL
by Vladimir Shabanov 17 Sep '16

17 Sep '16

Hello, I would like to become a new maintainer for HsOpenSSL package. Package was last updated on January 6, 2015 and no new commits at https://github.com/phonohawk/HsOpenSSL since then. My pull request https://github.com/phonohawk/HsOpenSSL/pull/40 is waiting here for more than a year. And there are ten more ignored pull requests. I've mailed current maintainer https://github.com/phonohawk/ pho(a)cielonegro.org four months ago and received no answer. Since there are no other maintainers I want to become the one. Who am I? Developer of BazQux Reader which is a commercial Haskell application that uses HsOpenSSL 24x7 in its crawler. Will be glad to hear any suggestions or objections. If not, I'm planning to wait for a few weeks and ask Hackage admins for maintenance rights.

1 0

help wanted: hledger
by Simon Michael 17 Sep '16

17 Sep '16

Hey all, I believe hledger (http://hledger.org) is a useful project, with potential to be much better. I have more ideas and know-how than free time. By now the project has a fairly large surface area, such that I'm often avoiding it when I have only small chunks of time to work on something. So I'm putting out the call for help! I'm grateful for the occasional contributions over the last 9 years, and I would welcome more collaborators to share the work. That sounds appealing, right ? Really, this is a fun project, since you can use it to save money and time and build your wealth-accumulation skills. And as an active contributor, you will have access to free tutoring from a 9y haskeller, 20y consultant and FOSS developer, and 30y coder (that's me). Here are some particular areas needing help: - Release 0.28 (or should it be 1.0 ?) has been pending for a long time, partly because hledger, hledger-ui, hledger-web & hledger-api are released together. This is the number one priority at the moment. Also: - Integrate John Wiegley's ledger4 code as an additional parser, increasing our compatibility with Ledger, making hledger features more easily accessible to Ledger users. - Website beautification and marketing in general. - Contribute, solicit or raise funding, so we can sponsor developers/designers/minions, set meaningful issue bounties, etc. - UIs/integration for mobile/small-screen devices. - More import/export formats, easier migration to and from other tools. I hope you'll check out hledger and get involved. http://hledger.org -> Contribute Best! -Simon

1 0

Re: [Haskell-cafe] Very _very_ slow compiles on Windows 10
by Nicu Ionita 17 Sep '16

17 Sep '16

Sorry, I forgot to answer to all... ------ Originalnachricht ------ Von: "Nicu Ionita" <nicu.ionita(a)acons.at> An: "Malcolm Wallace" <malcolm.wallace(a)me.com> Gesendet: 17.09.2016 09:12:30 Betreff: Re[2]: [Haskell-cafe] Very _very_ slow compiles on Windows 10 >Oh, this could be a good hint! I don't have other protection except >windows defender, which is own Windows AV. (Reviews suggest that this >should be enough, altough on other PC - not with Windows 10 - I use >different AVs) But maybe the Windows own AV exhibits the same >behaviour. I will check this, thanks! >Nicu > >------ Originalnachricht ------ >Von: "Malcolm Wallace" <malcolm.wallace(a)me.com> >An: "Nicu Ionita" <nicu.ionita(a)acons.at> >Cc: "haskell-cafe(a)haskell.org" <haskell-cafe(a)haskell.org> >Gesendet: 17.09.2016 08:44:30 >Betreff: Re: [Haskell-cafe] Very _very_ slow compiles on Windows 10 > >>Do you have Symantec Endpoint Protection or similar antivirus? We >>found that under certain paranoid settings, even "ghc --version" >>took upwards of seven seconds, and compilation was slowed by a couple >>of orders of magnitude. We think the AV was scanning the (large) >>compiler binary, plus any DLLs it loads, plus the source, interface, >>and object files read and generated, On every invocation. Linking was >>absolutely dog slow. We also think the AV was deliberately throttled >>to never use more than 10% of CPU time, to avoid being noticeable to >>the user. >> >>It is possible that there are AV settings you can tweak to avoid the >>paranoia, and trust the compiler, and any other file that has already >>been scanned once. >> >> Regards, >> Malcolm (iPhone) >> >>On 17 Sep 2016, at 07:04, Nicu Ionita <nicu.ionita(a)acons.at> wrote: >> >>No virtualisation, it is a dual boot maschine. >>1 CPU would be good :-) In my case it is a very small fraction of it. >>Nicu >> >>------ Originalnachricht ------ >>Von: "A.M." <agentm(a)themactionfaction.com> >>An: haskell-cafe(a)haskell.org >>Gesendet: 17.09.2016 03:20:38 >>Betreff: Re: [Haskell-cafe] Very _very_ slow compiles on Windows 10 >> >>>On 09/16/2016 06:10 PM, Nicu Ionita wrote: >>>> Is anybody else experiencing really slow compilations with GHC >>>>7.10.2 on >>>> Windows 10? >>>> >>>> I use stack to compile the project and run it under a mingw64 >>>> environment provided by Github bash. The CPU usage is very low all >>>>the >>>> time (meaning: GHC does barely use the CPU). On same computer with >>>> Ubuntu 16.04 it just compiles normally, but under Windows it is for >>>>sure >>>> 10x slower, maybe even more. >>> >>>Are you using virtualization? I see the same thing under virtualbox >>>on >>>Ubuntu. Specifically, even after allocating 12 real CPUs to the VM, I >>>never see stack-invoked ghc use more than one CPU. On rare occasions, >>>the linker phase hangs. I have confirmed that ghc reports 12 >>>capabilities. >>> >>>I'm just glad that Windows is not my primary development platform; >>>it's >>>entirely possible that virtualization is the cause. VirtualBox is not >>>known for being a speed demon, but the compilation speed is indeed >>>embarrassing. >>> >>>Cheers, >>>M >>> >>> >>_______________________________________________ >>Haskell-Cafe mailing list >>To (un)subscribe, modify options or view archives go to: >>http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>Only members subscribed via the mailman list are allowed to post.

1 1

Looking for a source level debugger
by Nikita Karetnikov 17 Sep '16

17 Sep '16

Originally sent this to /r/haskell, but it doesn't show up there for some reason, so re-sending here. Is anyone aware of a source level debugger that can be used with GHC? That is, something integrated into an editor (as a plugin, perhaps) that can highlight the line being executed, show locals, etc. (Think of WinDbg without the registers window.) I'm mostly interested in something that can work on a Linux-based system, but solutions for other platforms are welcome, too! I've heard that Sublime can run on 3 OSes, is there a solution for it, for instance? P.S. I'm not looking for opinions on whether you think a debugger is necessary or not when programming in Haskell.

3 2

ANN: stack-1.2.0
by Emanuel Borsboom 17 Sep '16

17 Sep '16

See https://haskellstack.org for installation and upgrade instructions. Release notes: * On many Un*x systems, Stack can now be installed with a simple one-liner: wget -qO- https://get.haskellstack.org/ | sh * The fix for [#2175](https://github.com/commercialhaskell/stack/issues/2175) entails that stack must perform a full clone of a large Git repo of Hackage meta-information. The total download size is about 200 MB. Please be aware of this when upgrading your stack installation. * If you use Mac OS X, you may want to delay upgrading to macOS Sierra as there are reports of GHC panics when building some packages (including Stack itself). See [#2577]( https://github.com/commercialhaskell/stack/issues/2577) * This version of Stack does not build on ARM or PowerPC systems (see [store#37](https://github.com/fpco/store/issues/37)) Please stay with version 1.1.2 for now on those architectures. This will be rectified soon! * We are now releasing a [statically linked Stack binary for 64-bit Linux]( https://www.stackage.org/stack/linux-x86_64-static) Please try it and let us know if you run into any trouble on your platform. * We are planning some changes to our Linux releases, including dropping our Ubuntu, Debian, CentOS, and Fedora package repositories and switching to statically linked binaries. We would value your feedback in [#2534](https://github.com/commercialhaskell/stack/issues/2534). Major changes: * Add `stack hoogle` command. [#55](https://github.com/commercialhaskell/stack/issues/55) * Support for absolute file path in `url` field of `setup-info` or `--ghc-bindist` * Add support for rendering GHCi scripts targeting different GHCi like applications [#2457](https://github.com/commercialhaskell/stack/pull/2457) Behavior changes: * Remove `stack ide start` and `stack ide load-targets` commands. [#2178](https://github.com/commercialhaskell/stack/issues/2178) * Support .buildinfo files in `stack ghci`. [#2242](https://github.com/commercialhaskell/stack/pull/2242) * Support -ferror-spans syntax in GHC error messages. * Avoid unpacking ghc to `/tmp` [#996](https://github.com/commercialhaskell/stack/issues/996) * The Linux `gmp4` GHC bindist is no longer considered a full-fledged GHC variant and can no longer be specified using the `ghc-variant` option, and instead is treated more like a slightly different platform. Other enhancements: * Use the `store` package for binary serialization of most caches. * Only require minor version match for Docker stack exe. This way, we can make patch releases for version bounds and similar build issues without needing to upload new binaries for Docker. * Stack/Nix: Passes the right ghc derivation as an argument to the `shell.nix` when a custom `shell.nix` is used See [#2243](https://github.com/commercialhaskell/stack/issues/2243) * Stack/Nix: Sets `LD_LIBRARY_PATH` so packages using C libs for Template Haskell can work (See _e.g._ [this HaskellR issue]( https://github.com/tweag/HaskellR/issues/253)) * Parse CLI arguments and configuration files into less permissive types, improving error messages for bad inputs. [#2267](https://github.com/commercialhaskell/stack/issues/2267) * Add the ability to explictly specify a gcc executable. [#593](https://github.com/commercialhaskell/stack/issues/593) * Nix: No longer uses LTS mirroring in nixpkgs. Gives to nix-shell a derivation like `haskell.compiler.ghc801` See [#2259](https://github.com/commercialhaskell/stack/issues/2259) * Perform some subprocesses during setup concurrently, slightly speeding up most commands. [#2346](https://github.com/commercialhaskell/stack/pull/2346) * `stack setup` no longer unpacks to the system temp dir on posix systems. [#996](https://github.com/commercialhaskell/stack/issues/996) * `stack setup` detects libtinfo6 and ncurses6 and can download alternate GHC bindists [#257](https://github.com/commercialhaskell/stack/issues/257) [#2302](https://github.com/commercialhaskell/stack/issues/2302). * `stack setup` detects Linux ARMv7 downloads appropriate GHC bindist [#2103](https://github.com/commercialhaskell/stack/issues/2103) * Custom `stack` binaries list dependency versions in output for `--version`. See [#2222](https://github.com/commercialhaskell/stack/issues/2222) and [#2450](https://github.com/commercialhaskell/stack/issues/2450). * Use a pretty printer to output dependency resolution errors. [#1912](https://github.com/commercialhaskell/stack/issues/1912) * Remove the `--os` flag [#2227](https://github.com/commercialhaskell/stack/issues/2227) * Add 'netbase' and 'ca-certificates' as dependency for .deb packages. [#2293](https://github.com/commercialhaskell/stack/issues/2293). * Add `stack ide targets` command. * Enhance debug logging with subprocess timings. * Pretty-print YAML parse errors [#2374](https://github.com/commercialhaskell/stack/issues/2374) * Clarify confusing `stack setup` output [#2314](https://github.com/commercialhaskell/stack/issues/2314) * Delete `Stack.Types` multimodule to improve build times [#2405](https://github.com/commercialhaskell/stack/issues/2405) * Remove spurious newlines in build logs [#2418](https://github.com/commercialhaskell/stack/issues/2418) * Interpreter: Provide a way to hide implicit packages [#1208](https://github.com/commercialhaskell/stack/issues/1208) * Check executability in exec lookup [#2489](https://github.com/commercialhaskell/stack/issues/2489) Bug fixes: * Fix cabal warning about use of a deprecated cabal flag [#2350](https://github.com/commercialhaskell/stack/issues/2350) * Support most executable extensions on Windows [#2225](https://github.com/commercialhaskell/stack/issues/2225) * Detect resolver change in `stack solver` [#2252](https://github.com/commercialhaskell/stack/issues/2252) * Fix a bug in docker image creation where the wrong base image was selected [#2376](https://github.com/commercialhaskell/stack/issues/2376) * Ignore special entries when unpacking tarballs [#2361](https://github.com/commercialhaskell/stack/issues/2361) * Fixes src directory pollution of `style.css` and `highlight.js` with GHC 8's haddock [#2429](https://github.com/commercialhaskell/stack/issues/2429) * Handle filepaths with spaces in `stack ghci` [#2266](https://github.com/commercialhaskell/stack/issues/2266) * Apply ghc-options to snapshot packages [#2289](https://github.com/commercialhaskell/stack/issues/2289) * stack sdist: Fix timestamp in tarball [#2394](https://github.com/commercialhaskell/stack/pull/2394) * Allow global Stack arguments with a script [#2316](https://github.com/commercialhaskell/stack/issues/2316) * Inconsistency between ToJSON and FromJSON instances of PackageLocation [#2412](https://github.com/commercialhaskell/stack/pull/2412) * Perform Unicode normalization on filepaths [#1810](https://github.com/commercialhaskell/stack/issues/1810) * Solver: always keep ghc wired-in as hard constraints [#2453](https://github.com/commercialhaskell/stack/issues/2453) * Support OpenBSD's tar where possible, require GNU tar for xz support [#2283](https://github.com/commercialhaskell/stack/issues/2283) * Fix using --coverage with Cabal-1.24 [#2424](https://github.com/commercialhaskell/stack/issues/2424) * When marking exe installed, remove old version [#2373](https://github.com/commercialhaskell/stack/issues/2373) * Stop truncating all-cabal-hashes git repo [#2175](https://github.com/commercialhaskell/stack/issues/2175) * Handle non-ASCII filenames on Windows [#2491](https://github.com/commercialhaskell/stack/issues/2491) * Avoid using multiple versions of a package in script interpreter by passing package-id to ghc/runghc [#1957](https://github.com/commercialhaskell/stack/issues/1957) * Only pre-load compiler version when using nix integration [#2459](https://github.com/commercialhaskell/stack/issues/2459) * Solver: parse cabal errors also on Windows [#2502](https://github.com/commercialhaskell/stack/issues/2502) * Allow exec and ghci commands in interpreter mode. Scripts can now automatically open in the repl by using `exec ghci` instead of `runghc` in the shebang command. [#2510](https://github.com/commercialhaskell/stack/issues/2510) * Now consider a package to be dirty when an extra-source-file is changed. See [#2040](https://github.com/commercialhaskell/stack/issues/2040) Thanks to all our contributors for this release: * Aaron Friel * Andrew Cowie * AndrewRademacher * Anton Felix Lorenzen * Brian McKenna * Chris Done * Dan Aloni * danald * Daniel Casanueva * Denis * Denis Kasak * Emanuel Borsboom * erewok * Gabor Greif * Gurkenglas * Harendra Kumar * hesiod * Judah Jacobson * Khan Thompson * Mathieu Boespflug * Michael Sloan * Michael Snoyman * Mohit Agarwal * Moritz Angermann * Oleg Grenrus * Paolo G. Giarrusso * Philipp Kant * Ryan Desfosses * Sid Kapur * Sidharth Kapur * Simon Jakobi * Tim Dysinger * Tim Düsterhus * Tobias Markus * YPares * Yuriy Syrovetskiy * Yves Parès (Ywen) * ___

2 2

Re: [Haskell-cafe] Standard package file format
by Chris Kahn 17 Sep '16

17 Sep '16

I would like to second this thought. Using Haskell for package descriptions needs to be thought out and executed with great care and attention. It's really easy to go off the rails. Scala's build system lets you do very powerful things, but it also makes things unnecessarily complicated and mystifying for beginners. At my previous work where we used Scala extensively, there were many times where the team simply resorted to external tools because figuring out how to make some seemingly trivial change to an SBT module was too time consuming. On September 16, 2016 8:39:15 AM EDT, David McBride <toad3k(a)gmail.com> wrote: > While I would personally love having a package description in haskell, > I don't think it is a good idea. > > If you can't start or modify a package without already knowing > haskell, it is a huge barrier to entry. I remember trying to get > started in scala and having a lot of trouble with sbt because I didn't > know their operators for lists and arrays or hash tables or whatever > it is that they use in their files. > > On Fri, Sep 16, 2016 at 4:57 AM, yogsototh > <yann.esposito(a)gmail.com> wrote: >> >>> I guess the overriding question I have here is: what is the PROBLEM >>> being solved? >> >> Let me share my experience with Clojure and lein. They use a clojure >> hash-map for their configuration. So yes arbitrary code could be >> executed and I believe this is a _very good thing_. >> >> Why? Because it makes it very easy to add sub-configuration that can >> be used by third party plugin. For example: >> >> - a plugin that help the use of environment variables (lein-environ) >> which is really helpful for application development (not so much >> for library development) >> - a plugin that use S3 for our private dependencies (not supported by >> default by lein) >> >> >> For deployment: we were able to add request to our API server that >> provide not only the written version but also the git commit hash. So >> we could be certain of the version of the server. Too much time there >> were sys/admin deployment errors. And that could only be achieved >> because we were able to run arbitrary command in the project >> description file. >> >> I certainly forget many other advantages of having a package >> description format which is simply a data structure in the hosted >> language. But this has by far my preference. >> >> - cabal is ok, but very imperfect, I generally need to have a lot of >> copy/paste, I need to change it very often while writing >> application with many dependencies >> - JSON/YAML/TOML are simply not powerful enough to match all >> semantics we might need to configure a project. For example we >> might want to have Set instead of List for some properties. Or I >> don't know maybe ternary tree structures. >> >> The point is: we pay a price by adding a step between the semantic >> and the syntax. >> While if our configuration format was in Haskell we could express the >> semantic more directly. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. >

8 8

Issue with building executables using Cabal on Travis
by Geraldus 17 Sep '16

17 Sep '16

Hi Café! Recently we added an executable section to our Transient-Universe package and now Travis cabal builds always failing. The error message is: In-place registering transient-universe-0.3.4... Preprocessing executable 'monitorService' for transient-universe-0.3.4... [1 of 1] Compiling Main ( src/server/Transient/Monitor/Services/MonitorService.hs, dist/build/monitorService/monitorService-tmp/Main.o ) Linking dist/build/monitorService/monitorService ... No errors or warnings could be found in the package. Re-configuring with test suites enabled. If this fails, please run configure manually. Resolving dependencies... Configuring transient-universe-0.3.4... Package has no buildable test suites. Building source dist for transient-universe-0.3.4... Preprocessing library transient-universe-0.3.4... Preprocessing executable 'monitorService' for transient-universe-0.3.4... cabal: src/client/Transient/Move/Services/MonitorService.hs: does not exist Installing library in /home/travis/.cabal/lib/x86_64-linux-ghc-7.10.2/transient-universe-0.3.4-2OztnD6ZM7W2H3eixltaJX Installing executable(s) in /home/travis/.cabal/bin Warning: The directory /home/travis/.cabal/bin is not in the system search path. cabal: The file does not exist 'transient-universe-0.3.4.tar.gz'. (Full log — https://travis-ci.org/agocorona/transient-universe/jobs/160441018, you can see that other Cabal builds fail with same error, however all Stack builds are fine). This is a chunk of cabal file: extra-source-files: src/client/Transient/Move/Services/MonitorService.hs src/server/Transient/Move/Services/MonitorService.hs executable monitorService build-depends: base >4 && <5 if !impl(ghcjs >=0.1) hs-source-dirs: src/server/Transient/Monitor/Services build-depends: transformers , transient >=0.4.4 , transient-universe else hs-source-dirs: src/client/Transient/Monitor/Services main-is: MonitorService.hs default-language: Haskell2010 ghc-options: -threaded -rtsopts Have anyone faced similar issue?

2 2

Re: [Haskell-cafe] Very _very_ slow compiles on Windows 10
by Phyx 17 Sep '16

17 Sep '16

> Is anybody else experiencing really slow compilations with GHC 7.10.2 on > Windows 10? The problem comes down to these lines https://github.com/ghc/ghc/blob/e5ecb2010514405ac1b9b1285a8a65c00a5fd4e0/li… The issue is that the entire Windows support in GHC Is mostly provided through POSIX support. Windows however isn't a POSIX system, and these APIs were implemented for compatibility and not performance. This is the reason why any I/O operation on GHC Windows will be significantly slower. This is the same reason why Console I/O is also much slower. Why Unicode support is a bit wonky etc. GHC Is currently just not using native Windows syscalls, because by large most developers of GHC don't use Windows. There are other issues (but I won't go in detail on the user list). We are trying to fix this, there are multiple tickets open such as https://ghc.haskell.org/trac/ghc/ticket/11394 but it's a big task and there are very limited resources so priority is given to things currently broken rather than just slow.

1 0

Very _very_ slow compiles on Windows 10
by Nicu Ionita 17 Sep '16

17 Sep '16

Is anybody else experiencing really slow compilations with GHC 7.10.2 on Windows 10? I use stack to compile the project and run it under a mingw64 environment provided by Github bash. The CPU usage is very low all the time (meaning: GHC does barely use the CPU). On same computer with Ubuntu 16.04 it just compiles normally, but under Windows it is for sure 10x slower, maybe even more. Nicu

3 3

Re: [Haskell-cafe] [Haskell-community] Standard package file format
by Paolo Giarrusso 16 Sep '16

16 Sep '16

On 16 September 2016 at 12:13, Patrick Pelletier <ppelleti(a)funwithsoftware.org> wrote: > On 9/16/16 2:36 AM, Paolo Giarrusso wrote: >> >> (Resending from right address) >> >> We're talking about *three* options: >> 1. syntax for pure Haskell values, which I'll call HSON (Haskell >> jSON). That's just an alternative to YAML/TOML/... That would need >> extensions to allow omitting optional fields entirely. >> 2. a pure Haskell embedded domain-specific language (EDSL) that simply >> generates cabal description records (GenericPackageDescription >> values). That would allow abstraction over some patterns but not much >> more. But that alone is already an argument for EDSLs—the one Harendra >> already presented. >> 3. a Haskell embedded domain-specific language (EDSL) designed for an >> extensible build tool, like Clojure's (apparently), SBT for Scala or >> many others. That would potentially be a rabbit hole leading to a >> rather *different* tool—with a different package format to boot. That >> can't work as long as all libraries have to be built using the same >> tool. But stack and cabal are really about how to manage package >> databases/GHC/external environments, while extensible build tools are >> about (a more powerful form) of writing custom setup scripts. I >> suspect some extensions might be easier if more of the actual building >> was done by the setup script, but I'm not sure. > > > Options 2 and 3 both require running Haskell code at build time. > But if all packages had to use the new EDSL, then cross-compilation would essentially become impossible. "All packages migrate to new format" doesn't seem really a plausible option, as I already hinted in the text you quote. There are multiple JVM build tools because they're interoperable (like cabal-install and Stack): each library picks its own build tool, but they can still be linked together. Hpack generates cabal files, stack reuses cabal or hpack files. In principle, option 2 just needs a non-cross-compiled program to produce a package description—say by producing a cabal file. You just need to runghc it, either via ghci or by compiling and running a binary. Option 3 can be trickier depending on details, but the as long as you account for cross-compilation in the design it should be doable. For Template Haskell the problem is deeper (see http://blog.ezyang.com/2016/07/what-template-haskell-gets-wrong-and-racket-…) so let's *not* use it here. -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/

2 3

[Haskell-community] Standard package file format
by Paolo Giarrusso 16 Sep '16

16 Sep '16

(Resending from right address) We're talking about *three* options: 1. syntax for pure Haskell values, which I'll call HSON (Haskell jSON). That's just an alternative to YAML/TOML/... That would need extensions to allow omitting optional fields entirely. 2. a pure Haskell embedded domain-specific language (EDSL) that simply generates cabal description records (GenericPackageDescription values). That would allow abstraction over some patterns but not much more. But that alone is already an argument for EDSLs—the one Harendra already presented. 3. a Haskell embedded domain-specific language (EDSL) designed for an extensible build tool, like Clojure's (apparently), SBT for Scala or many others. That would potentially be a rabbit hole leading to a rather *different* tool—with a different package format to boot. That can't work as long as all libraries have to be built using the same tool. But stack and cabal are really about how to manage package databases/GHC/external environments, while extensible build tools are about (a more powerful form) of writing custom setup scripts. I suspect some extensions might be easier if more of the actual building was done by the setup script, but I'm not sure. On 16 September 2016 at 10:57, yogsototh <yann.esposito(a)gmail.com> wrote: > >> I guess the overriding question I have here is: what is the PROBLEM being >> solved? > > > Let me share my experience with Clojure and lein. They use a clojure > hash-map for their configuration. So yes arbitrary code could be executed > and I believe this is a _very good thing_. > > Why? Because it makes it very easy to add sub-configuration that can be used > by third party plugin. For example: > > - a plugin that help the use of environment variables (lein-environ) which > is really helpful for application development (not so much for library > development) > - a plugin that use S3 for our private dependencies (not supported by > default by lein) > > > For deployment: we were able to add request to our API server that provide > not only the written version but also the git commit hash. So we could be > certain of the version of the server. Too much time there were sys/admin > deployment errors. And that could only be achieved because we were able to > run arbitrary command in the project description file. > > I certainly forget many other advantages of having a package description > format which is simply a data structure in the hosted language. But this has > by far my preference. > > - cabal is ok, but very imperfect, I generally need to have a lot of > copy/paste, I need to change it very often while writing application with > many dependencies > - JSON/YAML/TOML are simply not powerful enough to match all semantics we > might need to configure a project. For example we might want to have Set > instead of List for some properties. Or I don't know maybe ternary tree > structures. > > The point is: we pay a price by adding a step between the semantic and the > syntax. > While if our configuration format was in Haskell we could express the > semantic more directly. > > _______________________________________________ > Haskell-community mailing list > Haskell-community(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/

2 1

Porting Haskell/C on Windows
by Harendra Kumar 15 Sep '16

15 Sep '16

Hi, When porting a package with C source in it which C compilers should it be portable to? Can we just assume gcc (MinGW) or are there any other compilers as well that work with ghc? -harendra

1 0

Data constructor ‘Minus’ comes from an un-promotable type ‘Ints’
by Nicholls, Mark 15 Sep '16

15 Sep '16

Hello, I clearly don’t really know what I’m doing…but at least I know it…. Here we defined the Naturals…and then attempt to construct the Integers…. > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE ExplicitForAll #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE StandaloneDeriving #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE ScopedTypeVariables #-} > import Prelude hiding (head, tail, (++), (+), replicate) > import qualified Prelude as P naturals > data Nat where > Z :: Nat > S :: Nat -> Nat I can now define + and * and prove things about them…1 * x == x etc….nice..but lets put that on one side. Borrow bits and bobs from singletons > data family Sing (a :: k) Borrow bits and bobs from singletons..i.e. the isomorphic values…my proofs in nat now map to SNat…double nice. > type SNat = (Sing :: Nat -> *) Create the integers by following my nose……(the integers are the equivalence class of pairs of naturals….) i.e. we have “positive” or “negative” or “zero”… > data Ints (a :: Nat) (b :: Nat) where > Minus :: SNat a -> Ints 'Z a > Zero :: Ints 'Z 'Z > Plus :: SNat a -> Ints a 'Z > Ok….this works as a set of values….but…. I can’t prove anything about these because the data constructors for my integers aren’t “promotable”…..so I cant do the same trick I did with Nat. “:k Zero” ….. Data constructor ‘Zero’ comes from an un-promotable type ‘Ints’ In a type in a GHCi command: Zero I’ve tried rejigging this in various futile and ignorant manners….but the bottom line is its…”un-promotable”…..look at the docs, and it says something vague about GADT’s…but that isnt the problem directly. Is there a nifty way around this log jam? (I can start proving things about ‘(Nat,Nat)….but this will soon become a bit clumsy….) Or do I just stop here and wrestle with getting agda installed and lose another few months in the agda-café (which appears to be a very nice place somewhere in finland….hmmmm…I think that’s something different). (I’ve already allegedly descended into cabal hell following my nose with an agda install… setup.exe: The program cpphs version >=1.18.6 && <1.19 is required but the version found at C:\Users\nichom\AppData\Roaming\cabal\bin\cpphs.exe is version 1.19). computer science would be good, if it wasn’t for the computers. CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT.

5 11

Re: [Haskell-cafe] [Haskell-community] technical thoughts on stack
by Christopher Allen 15 Sep '16

15 Sep '16

What are you talking about? $ stack build simple-library-0.1.0.0: unregistering (local file changes: src/Lib.hs) simple-library-0.1.0.0: build Preprocessing library simple-library-0.1.0.0... [1 of 1] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Lib.o ) /home/callen/work/simple-library/src/Lib.hs:7:3: warning: [-Wunused-do-bind] A do-notation statement discarded a result of type ‘[Char]’ Suppress this warning by saying ‘_ <- return "woot"’ Preprocessing executable 'simple-library-exe' for simple-library-0.1.0.0... On Wed, Sep 14, 2016 at 2:10 PM, Patrick Pelletier <ppelleti(a)funwithsoftware.org> wrote: > On 9/14/16 10:47 AM, David Feuer wrote: >> >> >> While we're griping about stack: it seems to place compiler output from >> -ddump-... in mysterious places that are hard to find without Google, and >> (worse) it seems to do something with stack test output that even Google >> can't discover. >> > > Also, compiler warnings get squirreled away in a file that I have to go > hunting for. It would be nice to have an option to print warnings (for > local packages, not dependencies) to stderr. > > --Patrick > > > _______________________________________________ > Haskell-community mailing list > Haskell-community(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community -- Chris Allen Currently working on http://haskellbook.com

5 14

Re: [Haskell-cafe] technical thoughts on stack
by Olaf Klinke 14 Sep '16

14 Sep '16

I second Richard's observations about project-centered vs. compiler-centered workflows. I used to test all my code in ghci until cabal ended up installing two versions of the same package. Stack helped me to obtain a working Haskell environment again. But: While it is nicer to have the `real' code organized as a proper project, I still haven't figured out how to test individual modules in stack ghci without either loading the entire project or making an executable foo that imports the module and loading the executable with stack ghci project:exe:foo And I can't easily have a traditional GHC install alongside for testing since the haskell platform for the operating system uses a different base package. -- Olaf

1 0

[ANN] Call for Contributions: BOB 2017 - Berlin, Feb 24, 2017
by Stefan Wehr 14 Sep '16

14 Sep '16

BOB Conference 2017 "What happens when we use what's best for a change?" http://bobkonf.de/2017/en/cfp.html Berlin, February 24 Call for Contributions Deadline: October 30, 2016 You are actively engaged in advanced software engineering methods, implement ambitious architectures and are open to cutting-edge innovation? Attend this conference, meet people that share your goals, and get to know the best software tools and technologies available today. We strive to offer a day full of new experiences and impressions that you can use to immediately improve your daily life as a software developer. If you share our vision and want to contribute, submit a proposal for a talk or tutorial! Topics ------ We are looking for talks about best-of-breed software technology, e.g.: - functional programming - persistent data structures and databases - types - formal methods for correctness and robustness - abstractions for concurrency and parallelism - metaprogramming - probabilistic programming - ... everything really that isn’t mainstream, but you think should be. Presenters should provide the audience with information that is practically useful for software developers. This time, we’re especially interested in experience reports. But this could also take other forms, e.g.: - introductory talks on technical background - overviews of a given field - demos and how-tos Requirements ------------ We accept proposals for presentations of 45 minutes (40 minutes talk + 5 minutes questions), as well as 90 minute tutorials for beginners. The language of presentation should be either English or German. Your proposal should include (in your presentation language of choice): - an abstract of max. 1500 characters. - a short bio/cv - contact information (including at least email address) - a list of 3-5 concrete ideas of how your work can be applied in a developer’s daily life -additional material (websites, blogs, slides, videos of past presentations, …) Submit here: https://docs.google.com/forms/d/e/1FAIpQLSfFuyBhBTCOTS0zTXBzY1KVuKpumyIBTuc… Organisation - direct questions to bobkonf at active minus group dot de - proposal deadline: October 30, 2016 - notification: November 15, 2016 - program: December 1, 2016 NOTE: The conference fee will be waived for presenters, but travel expenses will not be covered. Speaker Grants -------------- BOB has Speaker Grants available to support speakers from groups under-represented in technology. We specifically seek women speakers and speakers who are not be able to attend the conference for financial reasons. Details are here: http://bobkonf.de/2017/en/speaker-grants.html Shepherding ----------- The program committee offers shepherding to all speakers. Shepherding provides speakers assistance with preparing their sessions, as well as a review of the talk slides. Program Committee ----------------- (more information here: http://bobkonf.de/2017/programmkomitee.html) - Matthias Fischmann, zerobuzz UG - Matthias Neubauer, SICK AG - Nicole Rauch, Softwareentwicklung und Entwicklungscoaching - Michael Sperber, Active Group - Stefan Wehr, factis research Scientific Advisory Board - Annette Bieniusa, TU Kaiserslautern - Torsten Grust, Uni Tübingen - Peter Thiemann, Uni Freiburg

1 0

GHCI segfault for program that works fine when compiled
by erik 14 Sep '16

14 Sep '16

Hello, I posted a question on Stackoverflow and reddit's /r/haskell today (see below), the gist of which was that GHCI segfaults when I attempt to create a connection to a Postgresql instance using a function from the postgresql-simple library; however, when I compile and run my code it works fine. I thought it was perhaps odd that GHCI would segfault when the compiled code worked fine (this is on GHC 8.0.1 and GHC 7.10.3), and then I discovered that if I start GHCI in the following way, I can create a connection to my database without any issues: $ stack ghci --library-profiling --ghci-options="-fexternal-interpreter" It seems likely that I have a weird install of Postgresql + postgresql-libpq (albeit probably not too weird for anyone on OSX who uses the EnterpriseDB installer, like I did). As a result, I was unsure if exploring this issue further would be of interest to anyone. Anyway, I am posting here because I was encouraged to do so by a commenter on my Stackoverflow question. In addition, in both places, I received the suggestion to open a GHC ticket, but owing to my limited experience in Haskell, I am hesitant to do so. I do not know how to get a real stack trace for my segfault. Moreover, I would likely require a fair bit of hand-holding to produce any useful data, and I wasn't sure if pursuing this any further would be of value to anyone. More information can be seen here: Stackoverflow question: http://stackoverflow.com/questions/39440416/ghci-segfault-when-creating-a-d… Reddit Thread: https://www.reddit.com/r/haskell/comments/52ht7h/i_have_a_ghci_segfault_for… Should I open a GHC ticket? If so, what are some good strategies for producing useful information for that ticket? Thanks, Erik

2 1

Workshop on Coalgebra, Horn Clause Logic, and Types
by Ekaterina Komendantskaya 13 Sep '16

13 Sep '16

Call for Papers, Presentations and Participation Workshop on Coalgebra, Horn Clause Logic Programming and Types 28-29 November 2016, Edinburgh, UK https://ff32.host.cs.st-andrews.ac.uk/lpti16/ =================================================== The workshop marks the end of the EPSRC Grant Coalgebraic Logic Programming for Type Inference, by K. Komendantskaya and J. Power and will consist of two parts: Part 1 - Semantics: Lawvere theories and Coalgebra in Logic and Functional Programming Part 2 - Programming languages: Horn Clause Logic for Type Inference in Functional Languages and Beyond We invite all colleagues working in related areas to present and share their results. We envisage a friendly meeting with many stimulating discussions, and therefore welcome presentations of already published research as well as novel results. Authors of original contributions will be invited to submit their papers to EPTCS post-proceedings. We especially encourage early career researchers to present and participate. ======================= Venue ----- The workshop will be held at the International Center for Mathematical Sciences, in Edinburgh city center, just 2 minutes walk from the Informatics Forum. Invited speakers and tutorials ------------------------------ * Relational Specification of type systems using Logic Programming, Ki Yung Ahn, Nanyang Techological University, Singapore * Logic programming for type inference in object-oriented languages, Davide Ancona, University of Genoa, Italy * Logic programming: laxness and saturation, John Power, University of Bath, UK * Classes for the masses, Claudio Russo, Microsoft Research Cambridge, UK * Comodels and interaction, Tarmo Ustalu, Tallinn University of Technology, Estonia =============================== Proceedings publication ----------------------- Presentations: We invite submission of 2-page extended abstracts via Easychair, by the 15th October 2016. These will be subject to light review process. Preliminary proceedings will be made available at the conference in electronic form. Post-proceedings: Authors presenting original work will be invited to submit full papers to the post-proceedings of the workshop. The post-proceedings volume will be published in Electronic Proceedings in Theoretical Computer Science and peer-reviewed according to EPTCS standards by the PC members. ================================ Important dates --------------- Extended Abstract Submission: 15 October, 2016 Author notification: 25 October, 2016 Workshop: 28–29 November, 2016 EPTCS post-proceedings invitations: 15 December, 2016 EPTCS final version submission: 30 January, 2017 ======================== Programme committee ------------------- Ki Yung Ahn, Nanyang Techological University, Singapore Davide Ancona, University of Genoa, Italy Filippo Bonchi, CNRS, ENS de Lyon, France Iavor Diatchki, Galois, Inc, USA Peng Fu, Heriot-Watt University, Edinburgh, UK Neil Ghani, University of Strathclyde, UK Patricia Johann, Appalachian State University, USA Ekaterina Komendantskaya, Heriot-Watt University, Edinburgh, UK Clemens Kupke, University of Strathclyde, UK J. Garrett Morris, University of Edinburgh, UK Fredrik Nordvall Forsberg, University of Strathclyde, UK John Power, University of Bath, UK Claudio Russo, Microsoft Research Cambridge, UK Martin Schmidt, DHBW Stuttgart and University of Osnabrueck, Germany Stephan Schulz, DHBW Stuttgart, Germany Aaron Stump, The University of Iowa, USA Niki Vazou, University of California, San Diego, USA Joe Wells, Heriot-Watt University, Edinburgh, UK Fabio Zanassi, Radboud University of Nijmegen, Netherlands Workschop chairs -------- Ekaterina Komendantskaya, Heriot-Watt University, UK John Power, University of Bath, UK Publicity chair --------------- František Farka, University of Dundee, UK and University of St Andrews, UK

1 0

Re: [Haskell-cafe] Haskell eXchange and related events -- Call for Participation
by Bence Kodaj 13 Sep '16

13 Sep '16

Hi all, If you haven't registered yet for the Haskell eXchange, please get in touch - I bought an early bird ticket but I cannot attend after all. I'd be happy to sell my ticket to anybody for 80 GBP (originally it was 95 GBP + VAT). Cheers, Bence On Friday, 9 September 2016 17:32:24 UTC+2, Andres Löh wrote: > > Hi everyone. > > As Tom Ellis has correctly pointed out in another thread, I should > have announced the Haskell eXchange on this list. Let me do that now: > > ===================================================================== > Haskell eXchange 2016 > London, 6-7 October 2016 > ===================================================================== > > The Haskell eXchange is a general Haskell conference aimed at Haskell > enthusiasts of all skill levels. The Haskell eXchange is organized > annually, and 2016 is its fifth year. For the second year in a row, the > venue will be Skills Matter’s CodeNode, where we have space for three > parallel tracks. New this year: a large number of beginner-focused > talks. At all times, at least one track will be available with a talk > aimed at (relative) newcomers to Haskell. Of course, there are also > plenty of talks on more advanced topics. > > Keynote speakers: > > Don Stewart, Conor McBride, Graham Hutton, Simon Peyton Jones > > Talks and workshops (some changes may still occur) by: > > Julian Arni, Christiaan Baaij, Thomas van Binsbergen, Mathieu Boespflug, > Lars Brünjes, Ben Clifford, Philip Cunningham, Tom Ellis, Matthias > Fischmann, Oleg Grenrus, Nickolay Kudasov, Robert Henderson, Csaba > Hruska, Robin Kay, Csongor Kiss, Steven Kutsch, Kris Jenkins, David > Luposchainsky, Neil Mitchell, Andrey Mokhov, Romeo Moura, Jann Müller, > Boldizsár Németh, Andor Penzes, Ivan Perez, Michał Płachta, Nicolas > Pouillard, Arian van Putten, Andrzej Rybczak, Jeremy Singer, Nicolas Wu > > Homepage and registration: > > https://skillsmatter.com/conferences/7276-haskell-exchange-2016 > > If you're interested in the Haskell eXchange, you might also be > interested in the Haskell eXchange Haskell Hackathon and/or in the > Haskell courses (2-day introductory, 1-day on types, 2-day on > performance) offered by Well-Typed on the surrounding days. More info > here: http://www.well-typed.com/blog/125/ > > Cheers, > Andres > > -- > Andres Löh, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com > > Registered in England & Wales, OC335890 > 250 Ice Wharf, 17 New Wharf Road, London N1 9RF, England >

1 0

Facing issue: "No instance for (Fractional a0) arising from a use of ‘it’ The type variable ‘a0’ is ambiguous"
by Balraj Singh 13 Sep '16

13 Sep '16

Hi, I am writing a sample code below and getting an error. Please help to resolve it: Code: import Data.List findLoot val [] = 0.0 findLoot val ((x:y:[]):xs) | val == 0 = 0.0 | val < y = ((fromIntegral val) * (fromIntegral x)) / fromIntegral y | val > y = ((div val y)*x) + (findLoot (mod val y) xs) Error: No instance for (Fractional a0) arising from a use of ‘it’ The type variable ‘a0’ is ambiguous Note: there are several potential instances: instance HasResolution a => Fractional (Fixed a) -- Defined in ‘Data.Fixed’ instance Integral a => Fractional (Ratio a) -- Defined in ‘GHC.Real’ instance Fractional Double -- Defined in ‘GHC.Float’ ...plus one other In the first argument of ‘print’, namely ‘it’ In a stmt of an interactive GHCi command: print it Sample Input and Output: Input 1:- val = 50 ((x:y:[]):xs) = [[120, 30], [100,50],[60, 20]] Output 1:- 180.0000 Input 2:- val = 10((x:y:[]):xs) = [[500,30]] Output 2:- 166.6667

2 2

Re: [Haskell-cafe] xls: A library for parsing MS excel spreadsheets
by David Feuer 12 Sep '16

12 Sep '16

Also important is the extent to which the maintainers are willing and able to change the library to respond to changes in users' needs and expectations. Parsec, for example, seems to have been largely supplanted by Megaparsec because it failed to evolve. And some libraries need to track developments in implementation techniques, either replacing old techniques or adding new ones alongside. On Sep 12, 2016 2:53 PM, "Joachim Durchholz" <jo(a)durchholz.org> wrote: The best signal is a compact description of what the library does, and, more importantly, what it does not do. Stability isn't a particularly interesting metric anyway. You want metrics like use case coverage, interface complexity, performance predictability, and you also want the update intensity over time (the shape of the curve correlates with kinds of team activity - you need to validate anything you infer from the curve, but it tells you what things to validate). Am 12.09.2016 um 11:49 schrieb Theodore Lief Gannon: > ...and, "it will probably be replaced by something meaningful in the > future." But it hasn't, nor has it been removed, and it's a better signal > than no signal at all. > > On Sun, Sep 11, 2016 at 4:01 AM, Tom Ellis < > tom-lists-haskell-cafe-2013(a)jaguarpaw.co.uk> wrote: > > On Sun, Sep 11, 2016 at 03:48:38AM -0700, Theodore Lief Gannon wrote: >> >>> In fact, there's a "Stability" field where you can indicate that it's >>> officially experimental. >>> >> >> Six years ago Simon Marlow pronounced that the "Stability" field was >> "mostly >> defunct now, and shouldn't be used" >> >> https://stackoverflow.com/questions/3841218/conventions- >> for-stability-field-of-cabal-packages/3847493#3847493 >> >> Tom >> > _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

2 1

xls: A library for parsing MS excel spreadsheets
by Harendra Kumar 12 Sep '16

12 Sep '16

Hi, Some time back I wrote a small Haskell library to parse the old MS excel format (.xls). There were libraries to parse ".xlsx" but there was none for ".xls". I uploaded it on github (https://github.com/harendra-kumar/xls) so that others looking for something similar can find and use it. -harendra

6 9

[ANN] hs-di; dependency injection library for Haskell; deterministic even for fairly arbitrary and complex IO code
by Milán Nagy 10 Sep '16

10 Sep '16

Hi, Are there people here who are interested in the techniques of unit testing, mocking, dependency injection? Reproducible, deterministic tests, even for fairly arbitrary and complex IO code? There is a recent project of mine that strives to do all of the above: https://github.com/Wizek/hs-di I'd be curious to hear what some of you may think about it. I'm also looking to find at least one other person who can get excited about the potential of these techniques; someone who could be interested in discussing certain details of this project and related questions.

1 0

Stable Random Number Generator?
by Christopher Howard 10 Sep '16

10 Sep '16

Hi. What would be a good library if I want a pseudo-RNG which is stable across platforms and compiler versions? By "stable" I mean always produces the same values after being given a particular seed. I have a number of projects which involve generating some kind of pattern or graphic, where the algorithm is either fed values from a RNG, or starts with initial conditions generated by an RNG. So, I want an RNG which which produce the same results when different users on different systems enter the same seed. -- https://qlfiles.net My PGP public key ID is 0x340EA95A (pgp.mit.edu)

4 3

Haskell conferences in Europe
by Damian Nadales 10 Sep '16

10 Sep '16

Hi, Do you know of any Haskell conferences in Europe for 2016/2017? Also, do you know if there is a centralized place where this information can be found? Thanks in advance, Damian.

5 6

Haskell eXchange and related events -- Call for Participation
by Andres Löh 09 Sep '16

09 Sep '16

Hi everyone. As Tom Ellis has correctly pointed out in another thread, I should have announced the Haskell eXchange on this list. Let me do that now: ===================================================================== Haskell eXchange 2016 London, 6-7 October 2016 ===================================================================== The Haskell eXchange is a general Haskell conference aimed at Haskell enthusiasts of all skill levels. The Haskell eXchange is organized annually, and 2016 is its fifth year. For the second year in a row, the venue will be Skills Matter’s CodeNode, where we have space for three parallel tracks. New this year: a large number of beginner-focused talks. At all times, at least one track will be available with a talk aimed at (relative) newcomers to Haskell. Of course, there are also plenty of talks on more advanced topics. Keynote speakers: Don Stewart, Conor McBride, Graham Hutton, Simon Peyton Jones Talks and workshops (some changes may still occur) by: Julian Arni, Christiaan Baaij, Thomas van Binsbergen, Mathieu Boespflug, Lars Brünjes, Ben Clifford, Philip Cunningham, Tom Ellis, Matthias Fischmann, Oleg Grenrus, Nickolay Kudasov, Robert Henderson, Csaba Hruska, Robin Kay, Csongor Kiss, Steven Kutsch, Kris Jenkins, David Luposchainsky, Neil Mitchell, Andrey Mokhov, Romeo Moura, Jann Müller, Boldizsár Németh, Andor Penzes, Ivan Perez, Michał Płachta, Nicolas Pouillard, Arian van Putten, Andrzej Rybczak, Jeremy Singer, Nicolas Wu Homepage and registration: https://skillsmatter.com/conferences/7276-haskell-exchange-2016 If you're interested in the Haskell eXchange, you might also be interested in the Haskell eXchange Haskell Hackathon and/or in the Haskell courses (2-day introductory, 1-day on types, 2-day on performance) offered by Well-Typed on the surrounding days. More info here: http://www.well-typed.com/blog/125/ Cheers, Andres -- Andres Löh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com Registered in England & Wales, OC335890 250 Ice Wharf, 17 New Wharf Road, London N1 9RF, England

1 0

Aeson parsing of GeoJSON geometries
by mike thomas 09 Sep '16

09 Sep '16

Hi all. Having returned to commercial software development after a 10 year break in environmental regulation and travel, it was not long before I was using my favorite language Haskell, fortunately, as part of my job this time. Haskell has changed in many ways since last I used it, and I am having an internal (lack of) knowledge collision with the problem below: As set out in the example below, given a polygon as GeoJSON from a Postgis enabled Postgres datasbase, I want to get to a list of Double tuples: [(Double,Double)], using Aeson, to draw some polygons. I am stopped at the point of dismembering the nested coordinate arrays. With Stackage nightly-2016-09-01 ghci, and the series of functions defined at the end of this message, I get a runtime type error regarding Vectors, which baffles me. Question 1. Why does Aeson nest the arrays using list syntax around the Array type constructor arguments? Question 2. How do I best convert this part of the AST: "(Array [Array [Array [Number 4.5305923601,Number 50.6585120423],Array [Number 4.5307511543,Number 50.657719833],Array [Number 4.5310580333,Number 50.657539732],Array [Number 4.5309023972,Number 50.6584422261],Array [Number 4.5308797482,Number 50.6586166629],Array [Number 4.5305923601,Number 50.6585120423]]])" to a list of Double tuples? I've tried several variations of the function dropOuterArray to try and resolve this run-time error, with no success. All help welcome, and thanks for your time Mike. ========= GHCI Session With Error ====================== p = parseGeoJSONGeometry "{\"type\":\"Polygon\",\"coordinates\":[[[4.5305923601,50.6585120423],[4.5307511543,50.657719833],[4.5310580333,50.657539732],[4.5309023972,50.6584422261],[4.5308797482,50.6586166629],[4.5305923601,50.6585120423]]]}" p (Just (String "Polygon"),Just (Array [Array [Array [Number 4.5305923601,Number 50.6585120423],Array [Number 4.5307511543,Number 50.657719833],Array [Number 4.5310580333,Number 50.657539732],Array [Number 4.5309023972,Number 50.6584422261],Array [Number 4.5308797482,Number 50.6586166629],Array [Number 4.5305923601,Number 50.6585120423]]])) p1 = dropOuterArrayJ (snd p) p1 [Array [Array [Number 4.5305923601,Number 50.6585120423],Array [Number 4.5307511543,Number 50.657719833],Array [Number 4.5310580333,Number 50.657539732],Array [Number 4.5309023972,Number 50.6584422261],Array [Number 4.5308797482,Number 50.6586166629],Array [Number 4.5305923601,Number 50.6585120423]]] p2 = dropOuterArray p1 :151:21: error: • Couldn't match type ‘Data.Vector.Vector Value’ with ‘Value’ Expected type: Value Actual type: Array • In the first argument of ‘dropOuterArray’, namely ‘p1’ In the expression: dropOuterArray p1 In an equation for ‘p2’: p2 = dropOuterArray p1 ============ Code ==================== {-# LANGUAGE OverloadedStrings, DeriveGeneric, DeriveAnyClass, ScopedTypeVariables, LambdaCase, FlexibleContexts #-} module GeoJSONGeometry ( parseGeoJSONGeometry ,Coordinates ,dropOuterArrayJ ,dropOuterArray ,Pt ,gTypeString ) where import Data.Aeson import Data.Aeson.Types --(parse, parseMaybe, parseEither, Value(..)) import GHC.Generics import Data.ByteString.Lazy.Char8 import Data.HashMap.Strict import qualified Data.Vector as V import Data.Either.Extra (fromRight) import Data.Maybe (fromJust) import Control.Applicative import Codec.Picture import Graphics.Rasterific import Graphics.Rasterific.Texture import GHC.Generics parseGeoJSONGeometry gjg = let eresult = (eitherDecode (pack gjg)) :: Either String Object -- Value -- Object result = (fromRight eresult) gType = Data.HashMap.Strict.lookup "type" result gCoords = Data.HashMap.Strict.lookup "coordinates" result in (gType, gCoords) gTypeString (Just (Data.Aeson.Types.String s)) = s dropOuterArrayJ (Just (Array u)) = u dropOuterArray (Array u) = u

2 1

many beautiful things
by dek5 08 Sep '16

08 Sep '16

Dear! Just take a look at this stuff! There are so many beautiful things here, you should visit the store <http://puquytrygy.kylejjackson.com/aeodqar> Sincerely yours, dek5

1 0

regex and Unicode
by Brian Sammon 08 Sep '16

08 Sep '16

I tried to write a program using Text.Regex.PCRE to search through a UTF8-encoded document. It appears that the presence of non-breaking-space characters (code point 160) triggers some weird behavior in my program. This is using the Debian stable(Jessie) packages of ghc 7.6.3 and libraries. Now I find myself at a fork in the road, not sure which direction to head in. Do I: 1) Continue looking (or get help with looking) for bugs in my code? (I have this reduced to a pretty small test case) 2) Assemble a bug-report against debian? 3) Assemble a bug-report against Text.Regex.PCRE (or Text.Regex.Base) for "upstream" 4) Uninstall Text.Regex.PCRE (and/or some other packages) and switch to something that works with Unicode/UTF8? Any ideas?

5 10

Summer 2017 Functional Programming / Math internship
by Siddharth Bhat 07 Sep '16

07 Sep '16

Hello, I'm a comp. sci undergrad student in my second year. I'm studying at IIIT-Hyderabad in India. I'm looking for companies that want summer interns for functional programming or pure mathematics related to FP (category theory, type theory, HoTT..). My github is here: http://github.com/bollu Math.stackexhcange: http://math.stackexchange.com/ users/261373/siddharth-bhat Thanks, Siddharth -- Sending this from my phone, please excuse any typos!

1 0

[ANN] brittany - haskell source code formatting tool - experimental/alpha
by lennart spitzner 06 Sep '16

06 Sep '16

Greetings, I am happy to announce a first alpha release of brittany (0.7.0.0), a haskell source code formatting tool based on ghc-exactprint [2] (and thus ghc's parser). https://github.com/lspitzner/brittany Two small feature cases that brittany would produce/leave unmodified: > -- Newlines are used sparingly: Only after "do" and when the > -- `liftBaseOpDiscard` application would lead to overflowing 80 columns. > main :: IO () > main = do > pool <- createPostgresqlPool (toS databaseConnectionString) 10 > initiate $ \chan -> forever $ do > flip runDbConn pool $ do > makeSureQueueIsFull chan > void $ liftBaseOpDiscard (consumeMsgs chan responseQueue Ack) > (uncurry processMsg) > threadDelay 1000000 > -- Alignment of patterns > go [] "" = True > go [WildCard ] "" = True > go (WildCard :rest) (c:cs) = go rest (c : cs) || go (WildCard : rest) cs > go (Union globs:rest) cs = any (\glob -> go (glob ++ rest) cs) globs > go [] (_:_) = False > go (_:_) "" = False Yet this is an alpha release, for the following reasons: - Brittany currently only transforms top-level type signatures and (function) bindings. - Not all syntactical constructs (even of plain 2010 haskell) are understood. All common constructs should work, but "common" is purely subjective. - Not all (syntactic) extensions are supported, either. - Needs more testing. (And less than a hundred automated testcases is not very much to explore every syntactic corner of haskell.) On the other hand - I have started using the tool successfully, albeit selectively. - There are checks in place that detect 1) if output is not valid haskell or 2) if source comments are not transcribed to the output. That is, running into non-handled cases should lead to error messages that are harmless, not into any silent it-overwrote-my-code-with-garbage. *How to build?* Brittany requires ghc-8. See https://github.com/lspitzner/brittany#building A hackage release is not planned yet. *Brittany's formatting style* Currently brittany does _not_ give the user many choices. A few flags exist, most prominently to change the indentation (default 2) or the columns (default 80). I am open to suggestions of how to improve the style, but trying to make everyone happy is not a fulfilling goal for me. *Implementation/documentation/performance* The implementation and its core ideas are not documented. The core algorithm in theory has linear complexity in input size; the implementation probably is quadratic dues to some misuses of plain lists or other such implementation details. Providing at least a high-level overview is on my to-do list. [1] https://github.com/lspitzner/brittany [2] https://hackage.haskell.org/package/ghc-exactprint -- lennart

2 1

Applicative Monoid instance
by Brian Hurt 06 Sep '16

06 Sep '16

This may be a stupid question, but I'm wondering why the following instance isn't in prelude: instance (Applicative m, Monoid a) => Monoid (m a) where mempty = pure mempty mappend a b = mappend <$> a <*> b ? I ask, because being able to use a WriterT (IO ()) STM a to debug complex STM expressions would be really nice. But it depends upon IO () being a monoid. Brian

5 4

[ANN] Microspec
by amindfv＠gmail.com 05 Sep '16

05 Sep '16

Happy to announce the release of a new, tiny property-based test framework: Microspec. Microspec has a clean RSpec/HSpec-style API, depends only on base and QuickCheck, runs unit and property-based tests, and is well under 500 lines of code. If you'd like to add tests to your code but don't like increasing the amount of code you depend on, give Microspec a try: https://hackage.haskell.org/package/microspec Happy hacking! Tom

1 0

[ANN] Darcs 2.12.1 release
by Guillaume Hoffmann 05 Sep '16

05 Sep '16

Hi all, The Darcs team is pleased to announce the release of Darcs 2.12.1. The most important changes are: * fixes for building with GHC 8 * drop support for GHC 7.6 and 7.8, i.e., require GHC 7.10 * improvements in `darcs whatsnew` output with irrelevant files (Ben Franksen) This release can be installed via cabal or (soon) stack. The 2.12 branch is also available as a darcs repository from http://darcs.net/releases/branch-2.12 . Thanks! Guillaume Hoffmann

1 0

PEPM 2017 Final Call for Papers (submission deadline extension: 30th Sep.)
by Jeremy Yallop 04 Sep '16

04 Sep '16

FINAL CALL FOR PAPERS Workshop on PARTIAL EVALUATION AND PROGRAM MANIPULATION (PEPM 2017) NEWS: Deadline extension to 30th September (see below) NEWS: Keynote talk by Neil Jones, DIKU (see below). http://conf.researchr.org/home/PEPM-2017 Paris, France, January 16th - 17th, 2017 (co-located with POPL 2017) PEPM is the premier forum for discussion of semantics-based program manipulation. The first ACM SIGPLAN PEPM symposium took place in 1991, and meetings have been held in affiliation with POPL every year since 2006. PEPM 2017 will be based on a broad interpretation of semantics-based program manipulation, reflecting the expanded scope of PEPM in recent years beyond the traditionally covered areas of partial evaluation and specialization. Specifically, PEPM 2017 will include practical applications of program transformations such as refactoring tools, and practical implementation techniques such as rule-based transformation systems. In addition, the scope of PEPM covers manipulation and transformations of program and system representations such as structural and semantic models that occur in the context of model-driven development. In order to maintain the dynamic and interactive nature of PEPM and to encourage participation by practitioners, we also solicit submissions of short papers, including tool demonstrations, and of posters. Scope ----- Topics of interest for PEPM 2017 include, but are not limited to: * Program and model manipulation techniques such as: supercompilation, partial evaluation, fusion, on-the-fly program adaptation, active libraries, program inversion, slicing, symbolic execution, refactoring, decompilation, and obfuscation. * Program analysis techniques that are used to drive program/model manipulation such as: abstract interpretation, termination checking, binding-time analysis, constraint solving, type systems, automated testing and test case generation. * Techniques that treat programs/models as data objects including metaprogramming, generative programming, embedded domain-specific languages, program synthesis by sketching and inductive programming, staged computation, and model-driven program generation and transformation. * Application of the above techniques including case studies of program manipulation in real-world (industrial, open-source) projects and software development processes, descriptions of robust tools capable of effectively handling realistic applications, benchmarking. Examples of application domains include legacy program understanding and transformation, DSL implementations, visual languages and end-user programming, scientific computing, middleware frameworks and infrastructure needed for distributed and web-based applications, embedded and resource-limited computation, and security. This list of categories is not exhaustive, and we encourage submissions describing applications of semantics-based program manipulation techniques in new domains. If you have a question as to whether a potential submission is within the scope of the workshop, please contact the programme chairs. Submission categories and guidelines ------------------------------------ Three kinds of submissions will be accepted: Regular Research Papers, Short Papers and Posters. * Regular Research Papers should describe new results, and will be judged on originality, correctness, significance and clarity. Regular research papers must not exceed 12 pages in ACM Proceedings style (including appendix). * Short Papers may include tool demonstrations and presentations of exciting if not fully polished research, and of interesting academic, industrial and open-source applications that are new or unfamiliar. Short papers must not exceed 6 pages in ACM Proceedings style (including appendix). * Posters should describe work relevant to the PEPM community, and must not exceed 2 pages in ACM Proceedings style. We invite poster submissions that present early work not yet ready for submission to a conference or journal, identify new research problems, showcase tools and technologies developed by the author(s), or describe student research projects. At least one author of each accepted contribution must attend the workshop and present the work. In the case of tool demonstration papers, a live demonstration of the described tool is expected. Suggested topics, evaluation criteria, and writing guidelines for both research tool demonstration papers will be made available on the PEPM 2017 web site. Student participants with accepted papers can apply for a SIGPLAN PAC grant to help cover travel expenses and other support. PAC also offers other support, such as for child-care expenses during the meeting or for travel costs for companions of SIGPLAN members with physical disabilities, as well as for travel from locations outside of North America and Europe. For details on the PAC programme, see its web page. Publication and special issue ----------------------------- All accepted papers, short papers and posters included, will appear in formal proceedings published by ACM Press. Accepted papers will be included in the ACM Digital Library. Authors of selected papers from PEPM 2016 and PEPM 2017 will also be invited to expand their papers for publication in a special issue of the journal Computer Languages, Systems and Structures (COMLAN, Elsevier). Keynote ------- Neil Jones (DIKU) will give the PEPM keynote talk, titled Compiling Untyped Lambda Calculus to Lower-level Code by Game Semantics and Partial Evaluation Best paper award ---------------- PEPM 2017 continues the tradition of a Best Paper award. The winner will be announced at the workshop. Submission ---------- Papers should be submitted electronically via HotCRP. https://pepm17.hotcrp.com/ Authors using LaTeX to prepare their submissions should use the new improved SIGPLAN proceedings style, and specifically the sigplanconf.cls 9pt template. Important Dates --------------- UPDATE: following feedback from potential authors, we have extended the PEPM submission dates by two weeks to avoid clashes with other events. The new deadlines are consequently strict, and there will be no further extensions. For Regular Research Papers and Short Papers: * Abstract submission : Tuesday 27th September 2016 * Paper submission : Friday 30th September 2016 * Author notification : Friday 4th November 2016 * Camera ready : Monday 28th November 2016 For Posters: * Poster submission : Tuesday 8th November 2016 * Author notification : Friday 18th November 2016 * Camera ready : Monday 28th November 2016 PEPM workshop: * Workshop : Monday 16th - Tuesday 17th January 2017 The proceedings will be published 2 weeks pre-conference. AUTHORS TAKE NOTE: The official publication date is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of your conference. The official publication date affects the deadline for any patent filings related to published work. (For those rare conferences whose proceedings are published in the ACM Digital Library after the conference is over, the official publication date remains the first day of the conference.). PEPM'17 Programme Committee --------------------------- Elvira Albert (Complutense University of Madrid, Spain) Don Batory (University of Texas at Austin, USA) Martin Berger (University of Sussex, UK) Sebastian Erdweg (TU Delft, Netherlands) Andrew Farmer (Facebook, USA) Matthew Flatt (University of Utah, USA) John Gallagher (Roskilde University, Denmark) Robert Glück (DIKU, Denmark) Jurriaan Hage (Utrecht University, Netherlands) Zhenjiang Hu (National Institute of Informatics, Japan) Yukiyoshi Kameyama (University of Tsukuba, Japan) Ilya Klyuchnikov (Facebook, UK) Huiqing Li (EE, UK) Annie Liu (Stony Brook University, USA) Markus Püschel (ETH Zurich, Switzerland) Ryosuke SATO (University of Tokyo, Japan) Sven-Bodo Scholz (Heriot-Watt University, UK) Ulrik Schultz (co-chair) (University of Southern Denmark) Ilya Sergey (University College London, UK) Chung-chieh Shan (Indiana University, USA) Tijs van der Storm (Centrum Wiskunde & Informatica, Netherlands) Jeremy Yallop (co-chair) (University of Cambridge, UK)

1 0

Data.Conduit.Binary question
by Michael Litchard 03 Sep '16

03 Sep '16

I'd like to use conduits to (1) read a binary file in chunks (2) take an md5 of that chunk (3) write the chunk to a file (4) write md5 to file. I'm looking at Data.Conduit.Binary. Do I want sourceFileRange for (1)?

2 2

Travis/Cabal help
by David Feuer 02 Sep '16

02 Sep '16

Gabriel Gonzalez has gotten Cabal benchmark integration working for containers, and then I broke it without realizing I'd done so because Travis CI wasn't building the benchmarks. When I got them working again locally and tried enabling them in .travis.yml (just adding --enable-benchmarks to the cabal configure line), things went kablooey: https://travis-ci.org/haskell/containers/jobs/156997144 Does anyone know how to interpret those entrails? Is this something that can be fixed?

4 8