- Haskell-Cafe - Haskell.org

Why did the number of LOC in GHC nearly triple in 2014!?
by Dimitri DeFigueiredo 06 Oct '16

06 Oct '16

Hello folks, I was looking at this: https://www.openhub.net/p/ghc/analyses/latest/languages_summary And was really surprised by the graph. Is this correct!? Did the complexity of GHC's codebase significantly increase in 2014? Can anybody shed a light on why that is? Cheers, Dimitri -- 2E45 D376 A744 C671 5100 A261 210B 8461 0FB0 CA1F

2 1

Re: [Haskell-cafe] Representing Hierarchies with Typeclasses
by Dimitri DeFigueiredo 06 Oct '16

06 Oct '16

I have looked at how to embedded object oriented systems into haskell for practical reasons. By far the best resource I found was Oleg Kiselyov and Ralph Lämmel's work: https://arxiv.org/pdf/cs/0509027.pdf It shows the multiple possibilities. I have used the idea of having a super class be a polymorphic type with a tail. data Point s = Pt { x :: Int, y:: Int, tail :: s} And then specializing the parameter s into your derived class type Radius = Int type Circle = Point Radius many times. But *be warned*, I try to avoid object hierarchies like the plague! They lead to code that is not reusable. You may want to consider other simpler possibilities. Here is one of my earlier experiments that may be useful to you (I no longer have the views expressed there). https://github.com/dimitri-xyz/inheritance-in-haskell Cheers, Dimitri -- 2E45 D376 A744 C671 5100 A261 210B 8461 0FB0 CA1F

2 1

Representing Hierarchies with Typeclasses
by Rahul Muttineni 06 Oct '16

06 Oct '16

Hi cafe, I want to embed Java class hierarchies in Haskell, but I am unable to find a clean way to do it. Assume the class hierarchy C derives from B derives from A. Partial Solution: --- type family Super (a :: *) :: * class Extends a b where supercast :: a -> b instance {-# INCOHERENT #-} (Class a, Class c, Super a ~ b, Super b ~ c) => Extends a c where data A data B data C type instance Super C = B type instance Super B = A instance Extends C B instance Extends B A -- This is fine and is successfully able to infer Extends C A, but it's redundant and cannot infer that Extends D A if we let Super D = C. Is there a way to only specify the parent-child relationship once and get GHC to infer the entire hierarchy without the use of UndecidableInstances? Other solutions I've tried which avoid redundancy cause an infinite loop in the context reduction step of GHC. Thanks, Rahul Muttineni

2 3

Speakers for a kickoff meetup on functional programming.
by Damian Nadales 05 Oct '16

05 Oct '16

Hi, I'm planning on organizing a Meetup group about Functional Programming in Eindhoven, for next year. Currently there is very few people doing that in this area (according to the few jobs available here), and I would like to promote it. Next to that I would like to advertise Haskell, but I wanted to start with a more broader scope. My current employer is willing to sponsor this, and hence I was looking which speakers could be possible to bring for the big opening event. My first question is which speakers you know in the FP world that can clearly convey the ideas on "why functional programming matter for your company". The idea is to try to spark the interest of the different stakeholders in this city (and region). Second, I've seen some material here and there on FP propaganda, but I would like to know which ones are you favorites. Thanks a lot in advance, Damian.

3 3

Re: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler)
by Olaf Klinke 03 Oct '16

03 Oct '16

I did not intend to start a Python-bashing thread. Most people on this list will agree on which language is superior. I did not intend to suggest that Haskell is still mainly a research language, nor that it should remain to be. I'd love to see more problems to be tackled with lenses, FRP or GADTs, just to show that it can be done this way. Maybe one day an idiom will prove superior to its competitors and take its place in whatever is the equivalent of base then. I am happy to have packages coexist that use either of String, Text, ByteString.Lazy or ByteString.Strict. I am a fan of the Unix philosophy: Do one thing, and do it well. There are modules in base that are very good examples of this: Data.Map provides just one data structure with a very easy interface, no newtypes, no typeclasses. The user needs no knowledge of how it is implemented, but the internals can be exposed if necessary. Control.DeepSeq provides one single typeclass to provide one single functionality. In Unix the glue between programs are streams of bytes. I feel that the glue between Haskell libraries should be lambda calculus and algebraic datatypes. So when you write a library that processes HTTP traffic as conduits: Provide a wrapper function whose type does not mention the conduit classes. When you write another efficient text library, provide fromString and toString functions, even if they are inefficient. As to what kind of batteries should be included: * I feel that Haskell already has an excellent set of containers for all sorts of tasks. * It has excellent parsers. * The web stuff seems less uniform, and my complaints about idioms apply. * To compete with other recent teaching languages, a really simple GUI library to use within ghci would be fine. (diagrams and GTK?) Quick Basic included "line" and "circle" commands to play with, even though the rest of the language did not prepare me for more advanced languages. * I know too little about the state of Haskell's number crunching libraries, but it seems that Vector is reasonably efficient nowadays. But what should I use to solve A*x = b? This is a problem so basic that is should be solved by a basic library. I like Peter's suggestion of an official wiki highlighting the state-of-the-art packages for common tasks. As to the versioning and backward compatibility issues of a standard library: In my eyes the whole concept of version numbers is broken. Dependencies should be stated in terms of type signatures. Olaf

11 20

Re: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler)
by Olaf Klinke 03 Oct '16

03 Oct '16

Can someone please define what exactly a "batteries included" standard library is? IMHO that Python-Haskell comparison is unfair. Although both claim to be general-purpose languages, the focus in Haskell certainly has been on language research for most of its life. I recently hacked together a web client in python, my first project in that language. Documentation is excellent. Yet I am still horrified I had to use a language that provides so few static guarantees to control megawatt machines. What puts me off Haskell nowadays is the direct result of Haskell's roots in language research: Often when I come across a package that does what I need, it uses the conduit, lens or another idiom, which are like a language in a language to learn. In milder ways Python seems to suffer the same problem. So please, developers: Write more batteries, but make them expose a neat lambda calculus interface if possible that can be combined freely with other batteries. Regards, Olaf

16 29

simple search for new contributors
by Takenobu Tani 02 Oct '16

02 Oct '16

Hi cafe, In relation to these [1][2], I pushed simple search in multiple wiki sites for new contributors. Haskell wiki search for multiple wiki sites https://takenobu-hs.github.io/haskell-wiki-search I'm glad if it would be useful. [1]: https://mail.haskell.org/pipermail/ghc-devs/2016-September/012830.html [2]: https://github.com/ghc-proposals/ghc-proposals/pull/10 Regards, Takenobu

1 0

nbody benchmark please
by Branimir Maksimovic 02 Oct '16

02 Oct '16

can someone put bang pattern with parameters in nbody benchmark program of mine as it is on my machine significantly faster just because of that: run :: Int -> Ptr Planet -> IO () run 0 _ = return () run !i !p = do advance p run (i-1) p PS I lost my account and if someone has it please do this for me ;) http://benchmarksgame.alioth.debian.org/u64q/program.php?test=nbody&lang=gh… Also author of site removed my knucleotide benchmark which was among fastest because I didn't use data.hashtable (which is slow), rather used my own (which is few lines of code)

1 0

Re: [Haskell-cafe] Proposal: add Monoid1 and Semigroup1 classes
by Mario Blažević 02 Oct '16

02 Oct '16

CC-ing the Café on class naming... On 2016-10-01 04:07 AM, Edward Kmett wrote: > I'm somewhat weakly against these, simply because they haven't seen > broad adoption in the wild in any of the attempts to introduce them > elsewhere, and they don't quite fit the naming convention of the other > Foo1 classes in Data.Functor.Classes > > Eq1 f says more or less that Eq a => Eq (f a). > > Semigroup1 in your proposal makes a stronger claim. Semgiroup1 f is > saying forall a. (f a) is a semigroup parametrically. Both of these > constructions could be useful, but they ARE different constructions. The standard fully parametric classes like Functor and Monad have no suffix at all. It makes sense to reserve the suffix "1" for non-parametric lifting classes. Can you suggest a different naming scheme for parametric classes of a higher order? I'm also guilty of abusing the suffix "1", at least provisionally, but these are different beasts yet again: -- | Equivalent of 'Functor' for rank 2 data types class Functor1 g where fmap1 :: (forall a. p a -> q a) -> g p -> g q https://github.com/blamario/grampa/blob/master/Text/Grampa/Classes.hs What would be a proper suffix here? I guess Functor2 would make sense, for a rank-2 type? > > If folks had actually been using, say, the Plus and Alt classes from > semigroupoids or the like more or less at all pretty much anywhere, I > could maybe argue towards bringing them up towards base, but I've seen > almost zero adoption of the ideas over multiple years -- and these > represent yet _another_ point in the design space where we talk about > semigroupal and monoidal structures where f is a Functor instead. =/ > > Many points in the design space, and little demonstrated will for > adoption seems to steers me to think that the community isn't ready to > pick one and enshrine it some place central yet. > > Overall, -1. > > -Edward > > On Fri, Sep 30, 2016 at 7:25 PM, David Feuer <david.feuer(a)gmail.com > <mailto:david.feuer@gmail.com>> wrote: > > I've been playing around with the idea of writing Haskell 2010 > type classes for finite sequences and non-empty sequences, > somewhat similar to Michael Snoyman's Sequence class in > mono-traversable. These are naturally based on Monoid1 and > Semigroup1, which I think belong in base. > > class Semigroup1 f where > (<<>>) :: f a -> f a -> f a > class Semigroup1 f => Monoid1 f where > mempty1 :: f a > > Then I can write > > class (Monoid1 t, Traversable t) => Sequence t where > singleton :: a -> t a > -- and other less-critical methods > > class (Semigroup1 t, Traversable1 t) => NESequence where > singleton1 :: a -> t a > -- etc. > > I can, of course, just write my own, but I don't think I'm the > only one using such. > > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org <mailto:Libraries@haskell.org> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries> > > > > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

5 4

Fwd: Alternative: you can fool many people some time, and some people many time, but...
by Corentin Dupont 02 Oct '16

02 Oct '16

Hi guys, I'm playing with the mysterious "some" and "many" from Control.Applicative. If I try: many $ Just 1 It just loops, I understand why: http://stackoverflow.com/questions/18108608/what-are-alterna tives-some-and-many-useful-for It seems that some and many are normally used in a context where something is consumed, and can be depleted, so the loop ends. But why doesn't this terminates? take 3 $ many $ Just 1 It's a recursive call, but the construction of the result should be lazy... -- ===================================== Corentin Dupont CREATE-NET OpenIoT Research Area - Senior Researcher Via alla Cascata 56/D - 38123 Povo, Trento - Italy e-mail: corentin.dupont(a)create-net.org Skype: corentin.dupont1 www.create-net.org ====================================== -- ===================================== Corentin Dupont CREATE-NET OpenIoT Research Area - Senior Researcher Via alla Cascata 56/D - 38123 Povo, Trento - Italy e-mail: corentin.dupont(a)create-net.org Skype: corentin.dupont1 www.create-net.org ======================================

2 2