- Haskell-Cafe - Haskell.org

HGamer3D 0.6.2
by Peter Althainz 04 Oct '15

04 Oct '15

Dear All, HGamer3D has some new features with version 0.6.2, see www.hgamer3d.org. Builds on Windows and Linux. with version 0.6 a switch was made towards a simpler structure and a new 3d library. regards Peter

1 0

Re: [Haskell-cafe] Parsing Atom feed link
by Adam Bergmark 02 Oct '15

02 Oct '15

Hi, This sounds like a good change to me! Are you willing to provide a patch (and maybe a testcase??) for this? - Adam On Sun, Sep 27, 2015 at 11:17 PM, fr33domlover <fr33domlover(a)riseup.net> wrote: > On Sat, 26 Sep 2015 10:15:24 +0200 > Francesco Ariis <fa-ml(a)ariis.it> wrote: > > > > > Since you have done the homework and this is rfc compliant, have you > > tried sending an email to the maintainer [1]? > > It seems an uncontroversial change and they are active (last version > > released in 2015), I bet they are be willing to fix this. > > > > [1] http://hackage.haskell.org/package/feed > > I sent the message to the maintainer too. I'm tempted to add a quick > temporary fix to my code, but hopefully this issue will get fixed soon > anyway. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >

2 2

Re: [Haskell-cafe] Concept for "equal but unknown"
by Olaf Klinke 02 Oct '15

02 Oct '15

To me this sounds like the Reader monad: You have a value that depends on something that is yet to be decided upon. data SomeCargo = SomeCargo { decide_attribute1 :: ContainerID -> Attr1 decide_attribute2 :: ContainerID -> Attr2 ... } data ConcreteCargo = ConcreteCargo { attribute1 :: Attr1 attribute2 :: Attr2 } withID :: SomeCargo -> ContainerID -> ConcreteCargo If the type ContainerID is searchable [1] then you can have an Eq instance even for the SomeCargo type. That is, two containers are equal if whenever the same ID gets assigned, they have the same properties. The technical term would be "indistinguishable in all contexts". -- Olaf [1] http://math.andrej.com/2008/11/21/a-haskell-monad-for-infinite-search-in-fi…

1 0

Call for Contributions - Haskell Communities and Activities Report, November 2015 edition (29th edition)
by Mihai Maruseac 02 Oct '15

02 Oct '15

Dear all, We would like to collect contributions for the 28th edition of the ============================================================ Haskell Communities & Activities Report http://www.haskell.org/haskellwiki/Haskell_Communities_and_Activities_Report Submission deadline: 30 October 2015 (please send your contributions to hcar at haskell.org, in plain text or LaTeX format, both are equally accepted) ============================================================ 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 us, so that we can contact the project leaders and ask them to submit an entry. * If you are working on a project that is looking for contributors, please write a short entry and submit it, mentioning that your are looking for contributors. The final report might have an index with such projects, provided we get enough such submissions. * 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, Mihai Maruseac and Alejandro Serrano Mena FAQ: Q: What format should I write in? A: The usual format is a LaTeX source file, adhering to the template that is available at: http://haskell.org/communities/05-2015/template.tex There is also a LaTeX style file at http://haskell.org/communities/05-2015/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 soon receive your old entry as a template (provided we have your valid email address). Please modify that template, rather than using your own version of the old entry as a template. _However_, if you don't want/have time to format the entry for LaTeX, you can submit it in any other format possible and we will be happy to convert it for the final report. Q: Can I include Haskell code? A: Yes. Please use lhs2tex syntax (http://www.andres-loeh.de/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 or .png format, then, PNG being preferred for simplicity. 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 simply ask us. 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. You can use HCAR to ask for more contributors to your project, it is a good way to gain visibility and traction. Q: If I do not update my entry, but want to keep it in the report, what should I do? A: Tell us 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 its destination, and not ended up in a spam folder? A: Prior to publication of the final report, we will send a draft to all contributors, for possible corrections. So if you do not hear from us within two weeks after the deadline, it is safer to send another mail and check whether your first one was received. -- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya

1 0

Haskell Tooling Infrastructure
by Alan & Kim Zimmerman 02 Oct '15

02 Oct '15

Now that I am finally turning back to HaRe, the question of infrastructure again comes up. Basically I woudl like to focus in the tool itself, but it can only be useful if it can deal with real world environments. This means properly managing all the different project and compiler environments, and being integrated into IDEs. The current version uses ghc-mod for the lower level interface, and a simple command line interface for the IDE integration. But I have a definite sense that as a community every tool maker is solving the same problems over and over, from ghc-mod to ide-backend to ghci-ng, and onwards. To start a discussion around some kind of architeccture that tool writers can develop agains, ide's can integrat against and ghc/cabal can eventually internalise, I have put some basic points down at https://github.com/RefactoringTools/HaRe/wiki/Requirements-for-IDE-GHC-inte… Regards Alan

2 2

Candidate Haskell Platform 7.10.2-a for use with OS X El Capitan
by Gershom B 02 Oct '15

02 Oct '15

The new OS X El Capitan release (out today) broke the method that Haskell Platform uses to install itself, due to new security features. In fact, if you upgrade your OS, you are also likely to (slightly) break your existing install. There is now a candidate new installer, available at http://downloads.haskell.org/~platform/7.10.2/Haskell%20Platform%207.10.2-a… Note that it is unsigned and you will have to give it permission to run, the usual way, by right clicking on it, and choosing "open" then explicitly allowing it to run. The central difference between this and the prior installer is just that it installs symlinks to ghc tools in the /usr/local tree rather than the /usr tree since the latter is now off limits due to new OS X security features. If you have a prior install and just want to "fix" it after your OS upgrade, no need to reinstall the whole platform. Just download and run the activate-hs shellscript from here: https://github.com/mzero/haskell-platform/blob/master/hptool/os-extras/osx/… Again, after a bit more testing we'll get this signed and released as the new official platform installer for OS X, but in the meantime, I wanted to make sure people were in the loop. Regards, Gershom

2 1

7.10.2 : Compilation slowdown.
by aditya siram 01 Oct '15

01 Oct '15

Hi all, Since upgrading to 7.10.2 from 7.8.4 I'm seeing a significant increase in compilation time. I understand this is a known issue but since I'm seeing something like a 3x slowdown but not across the board, I thought I'd ask. Compilation time for the library I'm writing has remained about the same. I am seeing the slowdown when compiling executables that use the library. There are no other dependencies except base so I'm guessing it something in my library causing the issue. I lean heavily on the FFI, OverlappingInstances and HList style programming in my library which leads me to believe that one of these is causing it. I am seeing no difference in compilation speeds by adding the per instance OVERLAPPING pragmas. Can anyone advise or instruct me on how to profile the compiler? Thanks! -deech

3 4

ANNOUNCE: Megaparsec – an improved and actively maintained fork of Parsec
by Artyom 01 Oct '15

01 Oct '15

Hello! I'd like to announce the release of Megaparsec, a fork of Parsec that has been in the works for the past 2 months. There's a lot of improvements and bugfixes under the hood – as well as a new test suite with 128 Quickcheck tests covering 80% of code (Parsec has only 3 tests, by the way) – but first I'd like to explain why a fork was needed, since forking a popular library is a pretty drastic measure and should be accompanied by an explanation. (A disclaimer: I've been given permission to announce the library, but I'm neither the author nor an expert on parsing.) Hackage: https://hackage.haskell.org/package/megaparsec Changelog (including a list of differences from Parsec): https://hackage.haskell.org/package/megaparsec/changelog Github: https://github.com/mrkkrp/megaparsec If you ever had any ideas about what Parsec should've done differently, or what amazing new combinators it should include, etc., post your ideas here: https://github.com/mrkkrp/megaparsec/issues Why fork Parsec instead of writing a new library ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There are many parsing libraries on Hackage; Parsec was one of the first to appear, and it's still the one that is recommended to beginners when they ask about doing parsing in Haskell. Most other libraries aren't exactly trying to compete with Parsec – instead they explore new directions. Like it or not, it remains a fact that a lot of people are being recommended Parsec, a lot of people are using Parsec, and a lot of people will probably continue to use Parsec since there's no clear alternative to it. Writing a new and *different* library probably won't change it. Even new and *similar* libraries (trifecta and attoparsec are similar enough) haven't removed the need for Parsec, only mitigated it somewhat. Perhaps one day trifecta or something else will completely replace Parsec, but right now we still have to put up with Parsec. So, what we need (or at least what would be nice to have) is simply a better Parsec. What's wrong with original Parsec ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Parsec's development has stagnated long ago; you'd have a hard time getting your pull request merged, even if the only thing it does is fixing a typo (I'm not even talking about anything more controversial than that). Parsec isn't perfect or bug-free, and there *is* a need for those pull requests – just look at its Github page, where you'll find 8 unmerged PRs (and 9 open issues): https://github.com/aslatter/parsec In addition to things that could be fixed but simply aren't, there are some inconveniences (and bugs!) that are hard to fix without breaking backwards compatibility: * “notFollowedBy eof” will just silently not do what you expect it to do (a bug old enough to be considered an undocumented feature) * “<|>” and “many” are redefined and so importing Text.Parsec clashes with Control.Applicative (this can't be trivially fixed in Parsec because its “<|>” has different precedence from Control.Applicative's “<|>”) * you can't wrap Parser into monad transformers (I'm talking about things like “WriterT [String] Parser a” – if this was possible, there'd be no need for “user state” baked into ParsecT) * “Text.Parsec.Token” is not flexible enough for many needs; if you depend on it, one day you may find that you have to copy the whole module to get the behavior you want (look at https://github.com/aslatter/parsec/issues/15 and https://github.com/aslatter/parsec/issues/24, for example). In short, there may be a lot of value in improving Parsec – and that's where Megaparsec comes in. What is Megaparsec and how is it different ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Megaparsec “reboots” the development of Parsec. It's not backwards compatible, but it *is* compatible enough to avoid having to rewrite all Parsec tutorials, and code written for Parsec can be converted to use Megaparsec pretty mechanically. Given that, I would recommend using Megaparsec instead of Parsec from now on, unless you need compatibility with GHCs older than 7.10. Here is a detailed account of some of the bigger changes: === Error reporting === Megaparsec's errors messages are significantly more accurate than Parsec's in some cases, as the following demonstration shows. Parsec: > parseTest (try (string "let") <|> string "lexical") "le" parse error at (line 1, column 1): unexpected end of input expecting "lexical" Megaparsec: > parseTest (try (string "let") <|> string "lexical") "le" parse error at line 1, column 1: unexpected "le" expecting "let" or "lexical" And here's another one, showing off how sometimes “try a <|> b” is a bit less harmful than usual. Just in case, I'm talking about this blog post: http://blog.ezyang.com/2014/05/parsec-try-a-or-b-considered-harmful/ If you don't want to read it in full, the gist of it is that if you use “try” too liberally, Parsec's error messages become much worse than they could be. In this example, we're trying to parse a simple version of Haskell's import statements, which can look either as “import Foo” or “import qualified Foo as B”. If you write a parser like this: try pQualifiedImport <|> pImport you will get an uninformative error message on the following input: import qualified Foo s B Specifically, the “try pQualifiedImport” branch will fail, and then the “pImport” branch will stumble upon “qualified” – while the actual error isn't there, but in misspelled “as”. The advice given in the blog post (“The scope of backtracking try should be minimized”) is good, and applies to Megaparsec just as well as it applies to Parsec. However, a curious thing is that in this particular case Parsec *should* be able to tell you that the error is in misspelled “as”, because Parsec implements the longest match rule – errors that occur later in text are given precedence over errors that occur earlier. The code is there, but somehow it doesn't do what it's supposed to do (and Megaparsec fixes that). Here's the code from the article, rewritten for Megaparsec: import Text.Megaparsec import qualified Text.Megaparsec.Lexer as L data Stmt = QualifiedImport String String | Import String deriving (Show) pStmt = try pQualifiedImport <|> pImport pImport = do keyword "import" Import <$> upperCaseIdentifier pQualifiedImport = do keyword "import" keyword "qualified" QualifiedImport <$> upperCaseIdentifier <*> (keyword "as" *> upperCaseIdentifier) upperCaseIdentifier = lexeme $ (:) <$> upperChar <*> many (alphaNumChar <|> oneOf "_.") lexeme = L.lexeme (hidden space) keyword = L.symbol (hidden space) And here are the error messages it produces. Megaparsec: > parseTest (pStmt >> eof) "import qualified Foo s B" parse error at line 1, column 22: unexpected 's' expecting "as" Parsec (with minor modifications): > parseTest (pStmt >> eof) "import qualified Foo s B" parse error at (line 1, column 8): unexpected "q" expecting uppercase letter === Integration with monad transformers === The key type of Parsec is “ParsecT” (others, such as “Parsec” and “Parser”, are just type synonyms). It lets you use parsers with other monads – for instance, if you use “ParsecT String () IO”, you can have IO in your parsers. This is the reason, by the way, why “char” has the type char :: Stream s m Char => Char -> ParsecT s u m Char instead of a simpler char :: Char -> Parser Char (If it was the latter, you wouldn't be able to use “char” and IO in the same parser.) However, even this type isn't general enough for all things you might want to do. Imagine that you want some parsers to generate warnings when they are run, and later you want to collect those warnings and do something with them. This sounds like what Writer was invented for, so you try to use it. Now all your parsers have this type: ParsecT String () (Writer [Warning]) (Where “Warning” is, say, a synonym for String.) Unfortunately, this is not how you should've composed ParsecT and Writer, because this way you don't get backtracking – in other words, if you try to do optional (try someParser) and someParser generates warnings but then fails, “optional” won't be able to make them disappear – they will still be recorded. Same with State – if you do x <* notFollowedBy y and “y” changes the state, this change will be recorded even tho it's not what you want most of the time. (You can use Parsec's internal state and it *will* work, but it doesn't help you when you want to use Writer or something else instead of State.) What you want in such situations is WriterT [Warning] Parser () StateT YourState Parser () ... but you can't get it because “char” and all other primitive parsers simply don't have those types. With Parsec, the only solution is to apply “lift” to all parsers you want to use, which is pretty annoying. Megaparsec solves this by introducing an mtl-style “MonadParsec” class, making primitive parsers members of this class, and providing instances of MonadParsec for various monad transformers. (If you have ever used the ‘parsers’ library, you may recognise this approach.) I think being able to get backtracking behavior without relying on inelegant ways like “Parsec user state” is pretty neat, even if it's not something every Parsec user needs. === Lexing === Parsec has a lexing module (Text.Parsec.Token): http://hackage.haskell.org/package/parsec/docs/Text-Parsec-Token.html If you're not familiar with lexing, the idea is as follows. When you are parsing a programming language, you often have to solve the same set of problems – parsing numbers, string literals (with all those escaping rules), identifiers/operators/keywords, comments, making all parsers handle whitespace (since there can be whitespace between pretty much any 2 tokens), and so on. With “Text.Parsec.Token” you could just specify what counts as whitespace, as a comment, as an identifier character, etc. and get a set of parsers “for free”. Parsec achieves this by defining a huge structure called “GenLanguageDef” that contains the specification of your language: data GenLanguageDef s u m = LanguageDef { commentStart :: String, commentEnd :: String, commentLine :: String, nestedComments :: Bool, identStart :: ParsecT s u m Char, identLetter :: ParsecT s u m Char, opStart :: ParsecT s u m Char, opLetter :: ParsecT s u m Char, reservedNames :: [String], reservedOpNames :: [String], caseSensitive :: Bool } Then you use “makeTokenParser” on it to generate another huge structure containing lots of useful parsers: makeTokenParser :: GenLanguageDef ... -> GenTokenParser ... data GenTokenParser s u m = TokenParser { identifier :: ParsecT s u m String, operator :: ParsecT s u m String, charLiteral :: ParsecT s u m Char, stringLiteral :: ParsecT s u m String, natural :: ParsecT s u m Integer, integer :: ParsecT s u m Integer, float :: ParsecT s u m Double, lexeme :: forall a. ParsecT s u m a -> ParsecT s u m a, parens :: forall a. ParsecT s u m a -> ParsecT s u m a, braces :: forall a. ParsecT s u m a -> ParsecT s u m a, comma :: ParsecT s u m String, colon :: ParsecT s u m String, ... } What's the problem with this approach? It's very inflexible – the moment you want to change something that wasn't supposed to be changed, you're on your own. Do you want to special-case “-- |” comments to use them as doc strings? The easiest solution is to copy the whole module into your own project: https://github.com/aslatter/parsec/issues/15 Do you want to handle newlines by yourself (for instance, to allow them to be expression separators)? The easiest solution is to fork Parsec: https://github.com/aslatter/parsec/issues/24 (Even if those turn out not to be the easiest solutions, it's still somewhat telling that they were what the authors ended up with.) Megaparsec uses a simpler, more flexible approach. See the docs here: https://hackage.haskell.org/package/megaparsec/docs/Text-Megaparsec-Lexer.h… The linked module provides 3 categories of functions: * “integer”, “decimal”, “float”, “charLiteral”, etc are generic parsers that you can use to parse... well, things that they are named after. Some of those – like “integer” – are occasionally useful even if you're not parsing any languages (how often did you have to write “read <$> many1 digit”? now you don't have to). * “skipLineComment” and “skipBlockComment” generate comment parsers, and “space” combines them together. You can make comment parsers arbitrarily complex before passing them to “space”, or you can write your own space-skipping combinator. * “lexeme”, “symbol”, and “symbol'” make lexemes out of things; a lexeme, by convention, expects no leading whitespace and skips all trailing whitespace. So, instead of having parsers being passed to each other under the hood, you now have to pass them by yourself – except that you don't actually have to do much passing, because you can just write import qualified Text.Megaparsec.Lexer as L lexeme = L.lexeme space symbol = L.symbol space and off you go: keyword = label "keyword" . symbol parens = between (symbol "(") (symbol ")") ... etc ... How you can help ~~~~~~~~~~~~~~~~ * Take a project, modify it to use Megaparsec, file an issue if you've encountered any difficulties. * Take a Parsec tutorial and rewrite it for Megaparsec. (And then please send an email so that a link to your tutorial could be added to the README file.) * As I've already mentioned before, if you have any ideas about what could be changed/improved in Parsec, they likely apply to Megaparsec as well – propose them on the issue tracker. * Report typos in documentation (same goes for mistakes, unclear phrasing, etc). If you're shy (like me) and don't like opening issues, just ping me on IRC (I'm “indiagreen” on Freenode) if you spot anything.

6 6

SURVEY: How do you use Hackage?
by Rick Dzekman 01 Oct '15

01 Oct '15

I recently posted some criticisms of the Haskell User Experience on my site. Afterwards Greshom B. and I had a brief chat over email about any recommendations I had. I suggested that the first step in improving the User Experience of any product is research. I think Hackage is something that needs looking at and we agreed that getting some qualitative data was really important. This survey is an attempt to find out how different people use Hackage. If you're able to participate in the survey, you can either submit a response on this webform <https://docs.google.com/forms/d/1YTqI4BNTQ5PHipsJqxvPMnLsxvz6GA_yHm_fO6RhK8…> or submit a response on Reddit <https://www.reddit.com/r/haskell/comments/3n0vaw/survey_how_do_you_use_hack…> . If you have any questions or comments please feel free to email: haskell-usability-survey(a)haskell.org Thanks, Rick Dzekman

1 0

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 145, Issue 41
by David Banas 01 Oct '15

01 Oct '15

Thanks for your reply, Tom. That last expression doesn’t seem to have the correct type: Prelude Control.Applicative> let l1 = \x f -> pure f <*> x Prelude Control.Applicative> :t l1 l1 :: Applicative f => f a -> (a -> b) -> f b Prelude Control.Applicative> let l2 = \x f -> fmap f x Prelude Control.Applicative> :t l2 l2 :: Functor f => f a -> (a -> b) -> f b Prelude Control.Applicative> let l3 = \x f -> ($ x) <*> pure f Prelude Control.Applicative> :t l3 l3 :: a1 -> a -> (a1 -> a -> b) -> b Is there a typo? Thanks, -db On Sep 29, 2015, at 9:08 AM, haskell-cafe-request(a)haskell.org wrote: > Message: 2 > Date: Tue, 29 Sep 2015 16:40:38 +0100 > From: Tom Ellis <tom-lists-haskell-cafe-2013(a)jaguarpaw.co.uk> > To: haskell-cafe(a)haskell.org > Subject: Re: [Haskell-cafe] Question, re: Typeclassopedia Ex. 4.2.1 > Message-ID: <20150929154037.GS14111@weber> > Content-Type: text/plain; charset=us-ascii > > On Tue, Sep 29, 2015 at 07:48:05AM -0700, David Banas wrote: >> pure (flip ($)) <*> x <*> pure f = (interchange) >> pure (flip ($)) <*> pure ($ f) <*> x = (homomorphism) > > For one thing, this step doesn't look right. <*> does not associate that > way. > > It's probably worth at least putting each expression into ghci to check they > have the same time > > Prelude> import Control.Applicative > Prelude Control.Applicative> let l = \x f -> pure (flip ($)) <*> x <*> pure f > Prelude Control.Applicative> :t l > l :: Applicative f => f a -> (a -> b) -> f b > Prelude Control.Applicative> let l2 = \x f -> pure (flip ($)) <*> pure ($ f) <*> x > Prelude Control.Applicative> :t l2 > l2 :: Applicative f => f (((a -> b1) -> b1) -> b) -> a -> f b > > I imagine you're probably going to want to go via ($ x) rather than ($ f), > and possibly use that 'pure f <*> x = fmap f x = ($ x) <*> pure f'. > > Tom

1 0