September 2013 - Haskell-Cafe

Re: [Haskell-cafe] OS X ghci problem
by Carter Schonwald 18 Sep '13

18 Sep '13

The ghci bug goes away when you use a ghc head snapshot from late summer? Great! On Wednesday, September 18, 2013, Jan-Philip Loos wrote: > Sadly I was not able to use your build directly, because ghc(i) > searched libs in a invalid path (it seems to be wired to one of your > directories). I tried to build this ghc version from source on my own, > without success beyond stage 1. This [1] is related to the build > failure. I tried new alex and happy versions, without any change. A > naive approach was to compile alex/happy with ghc_stage1 compiler, > without success (as I expected due missing TH). I tried several ghc > versions for bootstrapping and alex/happy rebuilding (i guess ghc > > 7.6 is necessary for a valid 7.7 alex/happy build with the new Bool > primops), without success too. > > Finally I ended in a fully self build ghc 7.7.20130730 ([2]) and with > this ghc I can confirm that this specific error with > Binding.GLFW.c'glfwInit is gone :) Thanks > > [1] http://www.mail-archive.com/ghc-devs@haskell.org/msg02357.html > [2] > http://darcs.haskell.org/ghcBuilder/uploads/tn23/ghc-7.7.20130730-src.tar.b… > > On Mon, Sep 16, 2013 at 2:52 PM, Christiaan Baaij > <christiaan.baaij(a)gmail.com <javascript:;>> wrote: > > Here's a binary dist of my build: > https://www.dropbox.com/s/d37rij0dnvjiqqy/ghc-7.7.20130915-x86_64-apple-dar… > > In case someone wants to confirm my findings. > > > > Cheers, > > > > Christiaan > > > > On Sep 16, 2013, at 2:24 PM, Christiaan Baaij < > christiaan.baaij(a)gmail.com <javascript:;>> wrote: > > > >> Hi, > >> > >> I saw the same issue/crash on my machine using ghc 7.6.3. > >> > >> I just build a "perf" build of GHC-head with > >> "85a9e2468dc74b9e5ccde0dd61be86219fd323a2" as the latest commit. > >> > >> Now running, I get: > >> 1) > cabal install bindings-glfw > >> 2) > ghci > >> 3) ghci> :m Bindings.GLFW > >> 4) ghci> Bindings.GLFW.c'glfwInit > >> 5) ghci> 1 > >> > >> And doing: > >> 1.) > cabal install GLFW-b > >> 2.) > ghci -package GLFW-b > >> 3.) ghci> import Graphics.UI.GLFW as GLFW > >> 4.) ghci> GLFW.init > >> 5.) ghci> True > >> > >> My platform: > >> - OSX 10.8.4 > >> - ghc(i) 7.7.20130915 > >> - cabal 1.18.0.1 (using 1.18.0 of the Cabal library) > >> - xcode cltools 4.6.2 > >> > >> So it seems that the new ghci linking infrastructure fixes things > >> > >> Cheers, > >> > >> Christiaan > >> > >> On Sep 14, 2013, at 9:00 PM, Jan-Philip Loos <maxdaten(a)gmail.com<javascript:;>> > wrote: > >> > >>>> What I do for GLFW is use a dylib, then you don't rely on GHCi's > static-ish linker. > >>>> The only wrinkle is figuring out where you want the dylib. > >>>> I think homebrew will put one in /usr/local/lib, which works out > nicely, but they don't have GLFW 3 yet. > >>>> Another option is to build the dylib yourself from the GLFW source > bundled with the GLFW-b package, then tell cabal where to find it. > >>> > >>> Hi, > >>> for me the problem relocates now to the "bindings-glfw" package, since > >>> the native bindings moved to this package and are wrapped up with > >>> "glfw-b". > >>> > >>> My way to the same exception already mentioned by Brian Lewis: > >>> 1) > cabal install bindings-glfw > >>> 2) > ghci > >>> 3) ghci> :m Bindings.GLFW > >>> 4) ghci> Bindings.GLFW.c'glfwInit > >>> 5) ghci terminates with exception: *** Terminating app due to uncaught > >>> exception 'NSInvalidArgumentException', reason: '-[NSAutoreleasePool > >>> init]: unrecognized selector sent to instance 0x7fc443c01b30' > >>> > >>> Anthony Cowley mentioned to use ghci with GLFW as a dylib, I have no > >>> clue how to do this. I built the according glfw version on my own as a > >>> dylib and loaded ghci with it explicitly, this didn't help. I guess > >>> the compiled bindings-glfw is already statically packed up. > >>> > >>> How can I get ghci to use the native glfw dylib in combination with > >>> bindings-glfw? If I have to compile bindings-glfw with different > >>> settings, which settings? I have some oversight over haskell but no > >>> really deep knowledge according to bindings and lib-loading of ghci, > >>> but I'm willing to learn it ;) > >>> > >>> My Platform: > >>> - OSX 10.8.5 > >>> - ghc(i) 7.6.3 > >>> - cabal 1.18.0.1 > >>> - xcode dev tools 4.6.3 > >>> > >>> Thanks and Greetings > >>> > >>> Jan > >>> _______________________________________________ > >>> Haskell-Cafe mailing list > >>> Haskell-Cafe(a)haskell.org <javascript:;> > >>> http://www.haskell.org/mailman/listinfo/haskell-cafe > >> > > >

1 0

Multi-param typeclass vs locally constrained typeclass methods
by Jacques Carette 18 Sep '13

18 Sep '13

Could someone please explain what the difference (if any!), in semantics is between class Foo f => Bar f g where method1 :: f a -> g a and class Bar' g where method2 :: Foo f => f a -> g a ? Maybe the translation of the above to something lower level might help. [Note: "f a -> g a" is just an example, and is not meaningful to the question]. The best answer would contain a design guideline for typeclasses, which would spell out conditions in which to use each variant. Jacques

2 2

future (editor) of HCAR?
by Janis Voigtlaender 18 Sep '13

18 Sep '13

Dear all, The Haskell Communities and Activities Report has been produced twice a year for more than ten years now: http://www.haskell.org/haskellwiki/Haskell_Communities_and_Activities_Report I have been responsible for producing it the last few years, which was fun. I am now looking to pass that on, handing over the HCAR to someone else. Any takers? Editing HCAR is a few days work per year, but it is also a great way to be involved in the Haskell community - you get a lot of news first hand. There are various procedures in place that automate some of the work, and if someone is interested in taking over, I'm very willing to help along, for example producing the next edition of the report together for a smooth transition. Below I attach the previous call for contributions, which also answers some basic questions about the report. For further questions about the process etc., anybody interested simply get in touch with me. Also, such a transition is a good opportunity to rethink model and processes. Maybe you (anybody on the mailing list) have completely new ideas for how the HCAR should be organized? How it could function better? What other purposes it could serve than it has so far? ... (Or even that HCAR in its existing form is not needed anymore, but could be replaced by something great new?) Best, Janis. -------- Original-Nachricht -------- Betreff: Call for Contributions - Haskell Communities and Activities Report, May 2013 edition Datum: Mon, 08 Apr 2013 21:56:19 +0200 Von: Janis Voigtländer <jv(a)informatik.uni-bonn.de> An: Haskell <haskell(a)haskell.org> Dear all, I would like to collect contributions for the 24th edition of the ================================================================ Haskell Communities & Activities Report http://www.haskell.org/haskellwiki/Haskell_Communities_and_Activities_Report Submission deadline: 1 May 2013 (please send your contributions to hcar at haskell.org, in plain text or LaTeX format) ================================================================ This is the short story: * If you are working on any project that is in some way related to Haskell, please write a short entry and submit it. Even if the project is very small or unfinished or you think it is not important enough --- please reconsider and submit an entry anyway! * If you are interested in an existing project related to Haskell that has not previously been mentioned in the HCAR, please tell me, so that I can contact the project leaders and ask them to submit an entry. * Feel free to pass on this call for contributions to others that might be interested. More detailed information: The Haskell Communities & Activities Report is a bi-annual overview of the state of Haskell as well as Haskell-related projects over the last, and possibly the upcoming six months. If you have only recently been exposed to Haskell, it might be a good idea to browse the previous edition --- you will find interesting projects described as well as several starting points and links that may provide answers to many questions. Contributions will be collected until the submission deadline. They will then be compiled into a coherent report that is published online as soon as it is ready. As always, this is a great opportunity to update your webpages, make new releases, announce or even start new projects, or to talk about developments you want every Haskeller to know about! Looking forward to your contributions, Janis (current editor) FAQ: Q: What format should I write in? A: The required format is a LaTeX source file, adhering to the template that is available at: http://haskell.org/communities/05-2013/template.tex There is also a LaTeX style file at http://haskell.org/communities/05-2013/hcar.sty that you can use to preview your entry. If you do not know LaTeX, then use plain text. If you modify an old entry that you have written for an earlier edition of the report, you should already have received your old entry as a template (provided I have your valid email address). Please modify that template, rather than using your own version of the old entry as a template. Q: Can I include Haskell code? A: Yes. Please use lhs2tex syntax (http://people.cs.uu.nl/andres/lhs2tex/) The report is compiled in mode polycode.fmt. Q: Can I include images? A: Yes, you are even encouraged to do so. Please use .jpg format, then. Q: Should I send files in .zip archives or similar? A: No, plain file attachements are the way. Q: How much should I write? A: Authors are asked to limit entries to about one column of text. A general introduction is helpful. Apart from that, you should focus on recent or upcoming developments. Pointers to online content can be given for more comprehensive or "historic" overviews of a project. Images do not count towards the length limit, so you may want to use this opportunity to pep up entries. There is no minimum length of an entry! The report aims for being as complete as possible, so please consider writing an entry, even if it is only a few lines long. Q: Which topics are relevant? A: All topics which are related to Haskell in some way are relevant. We usually had reports from users of Haskell (private, academic, or commercial), from authors or contributors to projects related to Haskell, from people working on the Haskell language, libraries, on language extensions or variants. We also like reports about distributions of Haskell software, Haskell infrastructure, books and tutorials on Haskell. Reports on past and upcoming events related to Haskell are also relevant. Finally, there might be new topics we do not even think about. As a rule of thumb: if in doubt, then it probably is relevant and has a place in the HCAR. You can also ask the editor. Q: Is unfinished work relevant? Are ideas for projects relevant? A: Yes! You can use the HCAR to talk about projects you are currently working on. You can use it to look for other developers that might help you. Q: If I do not update my entry, but want to keep it in the report, what should I do? A: Tell the editor that there are no changes. The old entry will typically be reused in this case, but it might be dropped if it is older than a year, to give more room and more attention to projects that change a lot. Do not resend complete entries if you have not changed them. Q: Will I get confirmation if I send an entry? How do I know whether my email has even reached the editor, and not ended up in a spam folder? A: Prior to publication of the final report, the editor will send a draft to all contributors, for possible corrections. So if you do not hear from the editor within two weeks after the deadline, it is safer to send another mail and check whether your first one was received.

2 1

cabal: internal error when reading package index
by Henk-Jan van Tuyl 18 Sep '13

18 Sep '13

L.S., I was trying to install a package from a local drive and got the following message: >cabal install Resolving dependencies... cabal: internal error when reading package index: could not read tar file entryThe package index or index cache is probably corrupt. Running cabal update might fix it. Then I tried cabal update: >cabal update Downloading the latest package list from hackage.haskell.org Skipping download: Local and remote files match. Note: there is a new version of cabal-install available. To upgrade, run: cabal install cabal-install Trying the command cabal install cabal-install gave the same internal error message as for the first command. What can I do about this? Regards, Henk-Jan van Tuyl -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

2 1

Telling Cassava to ignore lines
by Andrew Cowie 17 Sep '13

17 Sep '13

I'm happily using Cassava to parse CSV, only to discover that non-conforming lines in the input data are causing the parser to error out. let e = decodeByName y' :: Either String (Header, Vector Person) chugs along fine until line 461 of the input when "parse error (endOfInput) at ..." Ironically when my Person (ha) data type was all fields of :: Text it just worked, but now that I've specified one or two of the fields as Int or Float or whatever, it's mis-parsing. Is there a way to tell it to just ignore lines that don't parse, rather than it killing the whole run? Cassava understands skipping the *header* line (and indeed using it to do the -by-name field mapping). Otherwise the only thing I can see is going back to all the fields being :: Text, and then running over that as an intermediate structure and validating whether or not things parse to i.e. float. AfC Sydney

2 2

Opportunity with Machine Learning Startup in Northern California
by Charles Weitzer 17 Sep '13

17 Sep '13

Hello, My name is Charles Weitzer. I have two friends who have started a quantitative hedge fund. One has his PhD in CS from Stanford, while the other has his PhD in Statistics from Berkeley. Company has around 12 people currently. They have made some unpublished discoveries in the field of Machine Learning and in other areas as well. They are looking for an extremely talented software engineer. This position could be a simple software engineer, but it could also be where you are "The Man", basically the head of systems development. These guys are going to be the next big thing in terms of quantitative strategies and systems. They are rebuilding their current system and also designing a new system. You could work on either or both. The title and level of seniority is very flexible. As well, given their returns, this is a chance to become extremely wealthy. They are currently managing a very healthy amount of capital. FYI, I am retained by them. They are located in Northern California. Their blurb below is really is just a starting point in terms of possible initial responsibility and seniority. They are flexible for the right person. Talk soon, Charles Weitzer CEO\Senior Recruiter Charles Weitzer and Associates, Inc. Global Financial Recruiting Services Charles(a)CharlesWeitzer.com Voice: USA (510) 558-9182 Fast-growing systematic-trading firm seeks an exceptional software developer. You will architect and implement a diverse set of core infrastructures, including new production systems, scientific-computing environments, and modern data stores. We seek candidates with a proven track record of writing correct, well-designed software, solving hard problems and delivering complex projects on time. You should preferably have experience with high assurance, distributed, fault-tolerant systems. Experience with functional programming as well as soft real-time, low-latency, cache-friendly systems is a bonus. We are getting big fast. Willingness to take initiative, and a gritty determination to productize, are essential. Join a team that includes faculty at premier universities and PhD's from top-tier schools, led by the founder and CEO of a successful Internet infrastructure startup. You will have a high impact, and you can expect frequent interaction with the researchers, officers, and founders. Compensation and benefits are highly competitive.

1 0

Proposal: Pragma EXPORT
by Wvv 17 Sep '13

17 Sep '13

I suggest to add instead of (or with) export section Pragma EXPORT: We have 3 values: public, abstract and private. Data(with newtypes and types,..) could be public, like `Data(...)` or abstract `Data`. Other cases abstract = public. {-# EXPORT <smth> #-} pragma is valid till next {-# EXPORT <smth> #-}. We also can add local pragma: {-# EXPORT <smth> from #-} ... {-# EXPORT <smth> untill #-} Outside of block is rule of previous {-# EXPORT <smth> #-}. Finally we also have rule for 1: {-# EXPORT <smth> one #-} Example module C where {-# EXPORT public #-} data A1... data A2... {-# EXPORT abstract from #-} newtype A3... data A4... {-# EXPORT abstract until #-} type A5... {-# EXPORT private one #-} data A6... foo = ... {-# EXPORT private one #-} bar = ... baz = ... lorem = ... {-# EXPORT private #-} insput ... dolor = .. sit = ... {-# EXPORT public one #-} amen = ... consectetur = ... adipisicing = ... elit = ... sed = ... eiusmod = ... tempor = ... incididunt = ... {-# EXPORT public from #-} ut = ... labore = ... et = ... {-# EXPORT public until #-} dolore = ... magna = ... aliqua = ... is the same as module C ( A1(..) , A2(..) , A3 , A4 , A5(..) , foo , baz , lorem , amen , ut , labore , et ) where data A1... data A2... newtype A3... data A4... type A5... data A6... foo = ... bar = ... baz = ... lorem = ... insput ... dolor = .. sit = ... amen = ... consectetur = ... adipisicing = ... elit = ... sed = ... eiusmod = ... tempor = ... incididunt = ... ut = ... labore = ... et = ... dolore = ... magna = ... aliqua = ... We also could have complex pragma, like {-# EXPORT inherit one foo #-} bar=... Backward compatibility: module A where ... ~ module A where {-# EXPORT public #-} ... module B ( .... ) where ... ~ module B ( .... ) where {-# EXPORT private #-} ... -- View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-Pragma-EXPORT-tp5736547.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

5 7

Readable GHC 7.6.3 docs (Bootstrapped)
by Obscaenvs 17 Sep '13

17 Sep '13

At [1] you can find links to the GHC documentation that I use myself, since the official version is a bit too TimesNewRoman-y for my ..."developed" taste. It available in a downloadable Bzipped TAR aswell as being browsable online. [1] http://bugthunk.net/ /fredrik

5 5

Re: [Haskell-cafe] reifying typeclasses
by oleg＠okmij.org 17 Sep '13

17 Sep '13

Evan Laforge wrote: > I have a typeclass which is instantiated across a closed set of 3 > types. It has an ad-hoc set of methods, and I'm not too happy with > them because being a typeclass forces them to all be defined in one > place, breaking modularity. A sum type, of course, wouldn't have that > problem. But in other places I want the type-safety that separate > types provide, and packing everything into a sum type would destroy > that. So, expression problem-like, I guess. > > It seems to me like I should be able to replace a typeclass with > arbitrary methods with just two, to reify the type and back. This > seems to work when the typeclass dispatches on an argument, but not on > a return value. E.g.: If the universe (the set of types of interest to instantiate the type class to) is closed, GADTs spring to mind immediately. See, for example, the enclosed code. It is totally unproblematic (one should remember to always write type signatures when programming with GADTs. Weird error messages otherwise ensue.) One of the most notable differences between GADT and type-class--based programming is that GADTs are closed and type classes are open (that is, new instances can be added at will). In fact, a less popular technique of implementing type classes (which has been used in some Haskell systems -- but not GHC)) is intensional type analysis, or typecase. It is quite similar to the GADT solution. The main drawback of the intensional type analysis as shown in the enclosed code is that it breaks parametricity. The constraint Eq a does not let one find out what the type 'a' is and so what other operations it may support. (Eq a) says that the type a supports (==), and does not say any more than that. OTH, Representable a tells quite a lot about type a, essentially, everything. > types. It has an ad-hoc set of methods, and I'm not too happy with > them because being a typeclass forces them to all be defined in one > place, breaking modularity. A sum type, of course, wouldn't have that Why not to introduce several type classes, even a type class for each method if necessary. Grouping methods under one type class is appropriate when such a grouping makes sense. Otherwise, Haskell won't lose in expressiveness if a type class could have only one method. {-# LANGUAGE GADTs #-} module G where data TRep a where TInt :: TRep Int TChar :: TRep Char class Representable a where repr :: TRep a instance Representable Int where repr = TInt instance Representable Char where repr = TChar argument :: Representable a => a -> Int argument x = go repr x where -- For GADTs, signatures are important! go :: TRep a -> a -> Int go TInt x = x go TChar x = fromEnum x -- just the `mirror inverse' result :: Representable a => Int -> a result x = go repr x where -- For GADTs, signatures are important! go :: TRep a -> Int -> a go TInt x = x go TChar x = toEnum x t1 = argument 'a' t2 = show (result 98 :: Char)

3 3

Monomorphic containers, Functor/Foldable/Traversable WAS: mapM_ for bytestring
by Michael Snoyman 17 Sep '13

17 Sep '13

That's really funny timing. I started work on a very similar project just this week: https://github.com/snoyberg/mono-traversable It's not refined yet, which is why I haven't discussed it too publicly, but it's probably at the point where some review would make sense. There's been a bit of a discussion on a separate Github issue[1] about it. A few caveats: - The names are completely up for debate, many of them could be improved. - The laws aren't documented yet, but they mirror the laws for the polymorphic classes these classes are based on. - The Data.MonoTraversable module is the main module to look at. The other two are far more nascent (though I'd definitely appreciate feedback people have on them). I think this and mono-foldable have a lot of overlap, I'd be interested to hear what you think in particular John. Michael [1] https://github.com/snoyberg/classy-prelude/issues/18 On Wed, Sep 11, 2013 at 11:05 PM, John Lato <jwlato(a)gmail.com> wrote: > I agree with everything Edward has said already. I went through a similar > chain of reasoning a few years ago when I started using ListLike, which > provides a FoldableLL class (although it uses fundeps as ListLike predates > type families). ByteString can't be a Foldable instance, nor do I think > most people would want it to be. > > Even though I would also like to see mapM_ in bytestring, it's probably > faster to have a library with a separate monomorphic Foldable class. So I > just wrote one: > > https://github.com/JohnLato/mono-foldable > http://hackage.haskell.org/package/mono-foldable > > Petr Pudlak has done some work in this area. A big problem is that > foldM/mapM_ are typically implemented in terms of Foldable.foldr (or > FoldableLL), but this isn't always optimal for performance. They really > need to be part of the type class so that different container types can > have specialized implementations. I did that in mono-foldable, using > Artyom's map implementation (Artyom, please let me know if you object to > this!) > > pull requests, forks, etc all welcome. > > John L. > > > On Wed, Sep 11, 2013 at 1:29 PM, Edward Kmett <ekmett(a)gmail.com> wrote: > >> mapM_ is actually implemented in terms of Foldable, not Traversable, and >> its implementation in terms of folding a ByteString is actually rather slow >> in my experience doing so inside lens and isn't much faster than the naive >> version that was suggested at the start of this discussion. >> >> But as we're not monomorphizing Foldable/Traversable, this isn't a think >> that is able to happen anyways. >> >> -Edward >> >> >> On Wed, Sep 11, 2013 at 2:25 PM, Henning Thielemann < >> lemming(a)henning-thielemann.de> wrote: >> >>> >>> On Wed, 11 Sep 2013, Duncan Coutts wrote: >>> >>> For mapM etc, personally I think a better solution would be if >>>> ByteString and Text and other specialised containers could be an >>>> instance of Foldable/Traversable. Those classes define mapM etc but >>>> currently they only work for containers that are polymorphic in their >>>> elements, so all specialised containers are excluded. I'm sure there >>>> must be a solution to that (I'd guess with type families) and that would >>>> be much nicer than adding mapM etc to bytestring itself. We would then >>>> just provide efficient instances for Foldable/Traversable. >>>> >>> >>> I'd prefer to keep bytestring simple with respect to the number of type >>> extensions. Since you must implement ByteString.mapM anyway, you can plug >>> this into an instance definition of Traversable ByteString. >>> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> >> > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries > >

3 12