News aggregator

Call-for-help: Add XDGBDS support to `directory` package

libraries list - 0 sec ago
Hello *, I'd like to invite everyone with knowledge of the XDG Base Directory Specification[1] to contribute to https://github.com/haskell/directory/issues/6 From what I gathered, it appears to me that adhering to the XDGBD Spec (on Linux at least) is desirable and "strongly encouraged" by Linux distributions[2], so I think this ought to be implemented sooner rather than later (maybe even in time to be part of GHC 7.10.1) This issue was originally filed against GHC, since it affects the location of the `~/.ghc` folder (and fwiw this would also affect cabal's `~/.cabal` folder location). Thanks, hvr [1]: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html [2]: https://wiki.debian.org/XDGBaseDirectorySpecification
Categories: Offsite Discussion

Reassociating trees in Template Haskell AST's

Haskell on Reddit - 30 min 58 sec ago

Disclaimer: crossposted on StackOverflow.

I'm upgrading a library where I translate Haskell to another language. Right now I'm using Meta.Parse to read in a Haskell module, and get back its TemplateHaskell AST, as described here.

The problem I'm running into is that, when I run the parse, I get a bunch of infix operators parsed as UInfixE and UInfixP, meaning that they are of unresolved associativity.

The description of the associativity talks about how the Haskell compiler resolves these.

I'm wondering, is there a function avaliable which can do this reassociation on the trees I get from parsing? I'm looking for something like this:

reassoc :: [Dec] -> [Dec]

I could write the massive AST traversal that does this, but it seems like it would be a massive amount of boilerplate, and clearly the function already exists in some form (hopefully in a form that plays nice with TH).

Does such a thing exist? Is there an easy way to get rid of unresolved infix operators in the AST I get from parsing declarations?

Even a function which, given the Name of an operator, could give its precedence and associativity, would be very useful.

submitted by jmite
[link] [comment]
Categories: Incoming News

Are there ANY good game engines for haskell?

Haskell on Reddit - Fri, 10/24/2014 - 7:54pm

I want to write a really simple intractable physics simulation, and I can't for the life of me find a game engine (really meaning a graphics library with mouse and keyboard functionality). Does anyone know of a good one?

submitted by Undo_all
[link] [12 comments]
Categories: Incoming News

My first package on hackage - feedback please

Haskell on Reddit - Fri, 10/24/2014 - 6:03pm

I created my first package and would like to know if I'm doing things right. Everything from specifying the dependency versions correctly, to documentation tips, to missing cabal file information.

http://hackage.haskell.org/package/aeson-t

Also there's a good chance I should be using lenses or something to do the kinds of transformations that this library provides. I'm still kind of a beginner.

submitted by begriffs
[link] [comment]
Categories: Incoming News

The GHC Team: GHC Weekly News - 2014/10/24

Planet Haskell - Fri, 10/24/2014 - 5:43pm

Hi *,

Welcome to the weekly GHC news. This one will be short this week, as the preceding one occurred only on Monday - but we'll be going with Fridays from now on, so next week we'll hopefully see a longer list.

  • GHC 7.8.4 tickets have been in waiting, and the RC will be soon after Austin finishes some final merges and tests on his branch. We have not committed a time for the release after the RC, yet we would like people to please seriously test and immediately report any major showstoppers - or alert us of ones we missed.
  • For the ​ GHC 7.10 release, one of the major features we planned to try and merge was DWARF debugging information. This is actually a small component of larger ongoing work, including adding stack traces to Haskell executables. While, unfortunately, not all the work can be merged, we talked with Peter, and made a plan: our hope is to get ​Phab:D169 merged, which lays all the groundwork, followed by DWARF debugging information in the code generators. This will allow tools like gdb or other extensible debuggers to analyze C-- IR accurately for compiled executables. Peter has written up a wiki page, available at SourceNotes, describing the design. We hope to land all the core infrastructure in ​Phab:D169 soon, followed by DWARF information for the Native Code Generator, all for 7.10.1
  • This past week, a discussion sort of organically started on the #ghc IRC channel about the future of the LLVM backend. GHC's backend is buggy, has no control over LLVM versions, and breaks frequently with new versions. This all significantly impacts users, and relegates the backend to a second class citizen. After some discussion, Austin wrote up a ​ proposal for a improved backend, and wrangled several other people to help. The current plan is to try an execute this by GHC 7.12, with the goal of making the LLVM backend Tier 1 for major supported platforms.
  • You may notice ​https://ghc.haskell.org is now responds slightly faster in some cases - we've activated a caching layer (CloudFlare) on the site, so hopefully things should be a little more smooth.

Closed tickets this week: #9684, #9692, #9038, #9679, #9537, #1473.

Categories: Offsite Blogs

Building a REST Client

Haskell on Reddit - Fri, 10/24/2014 - 2:56pm
Categories: Incoming News

Typing an AST without loosing the Applicative / Monad instances

Haskell on Reddit - Fri, 10/24/2014 - 10:06am

Hi,

This is my expression tree and related combinators https://github.com/phaazon/ash/blob/master/src/Ash.hs.

I’d like to type it in order to typecheck at compile time so that I can’t, for instance, right an addition of a floating value and an integral value. With the current implementation, I use a nasty L (for litteral) data to represent typed values at runtime, which sucks to me since I have to write a function typecheck :: E a -> Maybe TypeError.

Any idea?

submitted by _skp
[link] [11 comments]
Categories: Incoming News

I have trust issues with Haskell, but I don't think they are justified.

Haskell on Reddit - Fri, 10/24/2014 - 8:23am

I have been a Haskell enthusiast for a while now, but haven't seriously committed to it on any large projects.

The combination of these things leads to this feeling:

  1. Though Haskell is used in some production settings, it doesn't have nearly the amount of use as the other languages/platforms I use.
  2. Sometimes things feel too easy. Like the fact that I don't have a thousand lines of framework setup and configuration. Or that I can just blindly put together things by their types and have them work.
  3. I don't really know what I would do if I ever did have a big problem, especially if this was for my individual business ventures (that is, no buckets of money to throw at the problem).

I am able to create software more easily, and it seems much more reliable, and this worries me.

Are these completely unfounded?

submitted by fear-of-flying
[link] [24 comments]
Categories: Incoming News

Project adoption proposals?

Haskell on Reddit - Fri, 10/24/2014 - 2:57am

It has recently been suggested to me that working with someone elses code might be a good way to break out of grown habits.

So I was thinking I will try to adopt an unmaintained project. Do you guys have any listings or proposals on which project might come in question? Other than that: Opinions on this idea?

Note: It's not that I have too much spare time, so I won't take on any projects that need a great amount of work to get to a usable state. More like embracing everything not invented here and try to work with what I get.

submitted by goliatskipson
[link] [5 comments]
Categories: Incoming News

Parse CSV / TSV file in Haskell - Unicode Characters

haskell-cafe - Fri, 10/24/2014 - 2:35am
Hi, I'm trying to parse a tab-delimited file using cassava/Data.Csv in Haskell. However, I get problems if there are "strange" (Unicode) characters in my CSV file. I'll get a parse error (endOfInput) then. According to the command-line tool "file", my file has a "UTF-8 Unicode text" decoding. My Haskell code looks like this: {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE OverloadedStrings #-} import qualified Data.ByteString as C import qualified System.IO.UTF8 as U import qualified Data.ByteString.UTF8 as UB import qualified Data.ByteString.Lazy.Char8 as DL import qualified Codec.Binary.UTF8.String as US import qualified Data.Text.Lazy.Encoding as EL import qualified Data.ByteString.Lazy as L import Data.Text.Encoding as E
Categories: Offsite Discussion

pattern matches are overlapped

haskell-cafe - Thu, 10/23/2014 - 7:23pm
This works fine keyboardAct a d p (SpecialKey KeyLeft) Down Modifiers {shift=Down, ctrl=Up, alt=Up} = do (x,y) <- get p p $= (x-0.1, y) This keyboardAct a d p (SpecialKey KeyLeft) Down shiftDown = do (x,y) <- get p p $= (x-0.1, y) where, shiftDown = Modifiers {shift=Down, ctrl=Up, alt=Up} gives me : KeyBindings.hs:32:1: Warning: Pattern match(es) are overlapped In an equation for `keyboardAct': keyboardAct angle delta p (SpecialKey KeyLeft) Down Modifiers {shift = Up, ctrl = Up, alt = Up} = ... keyboardAct is used several times via pattern matching, e.g. keyboardAct angle delta p (SpecialKey KeyLeft) Down Modifiers {shift=Up, ctrl=Up, alt=Up} = do (x,y) <- get p a <- get angle d <- get delta angle $= a+d and there are several more. So clearly, the pattern match is overlapped, just like the warning says. The question is why
Categories: Offsite Discussion

Danny Gratzer: Update on Old Projects

Planet Haskell - Thu, 10/23/2014 - 6:00pm
Posted on October 24, 2014 Tags: haskell, personal

All though most people I talk to know me for my blog, I do occasionally actually write software instead of just talking about it :)

Sadly, as a mercurial user most of my stuff has languished with on bitbucket. I’ve had a few people tell me that this is annoying for various reasons. Yesterday, I finally got around to fixing that!

As of yesterday, all of my interesting projects are mirrored on [github][my-github]. I’m still using mercurial but thanks to the lovely git-hg tool this is not an issue. You can fork, pull-request, or generally peek and poke as you please. From my end all of these actions look like nice mercurial changesets so I can continue to live under my rock where I don’t need to understand Git.

As a quick list of what haskell code is up there now

Which I think includes every project I’ve blogged about here as well as a few others. Sorry it took so long!

<script type="text/javascript"> /* * * CONFIGURATION VARIABLES: EDIT BEFORE PASTING INTO YOUR WEBPAGE * * */ var disqus_shortname = 'codeco'; // required: replace example with your forum shortname /* * * DON'T EDIT BELOW THIS LINE * * */ (function() { var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true; dsq.src = '//' + disqus_shortname + '.disqus.com/embed.js'; (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq); })(); </script> <noscript>Please enable JavaScript to view the comments powered by Disqus.</noscript> comments powered by Disqus
Categories: Offsite Blogs

Are list comprehensions idiomatic in modern Haskell style?

Haskell on Reddit - Thu, 10/23/2014 - 4:15pm

I've been noticing dozens of recent Stack Overflow questions asking how to do things specifically with list comprehensions ("I want to write a function that uses list comprehensions...") ("I'm trying to use list comprehension to return the list elements that differ from the next.") or otherwise has a map or other operation shoehorned into a comprehension ("capitalise str = [ toUpper x | x <- str ]").

My assumption is that these are all telltales of homework assignments of the form "Using a list comprehension..." or just a teacher somewhere that's really partial to the sugar.

My sense is that list comprehensions in general are rarely idiomatic in "production" these days; rather, we prefer to use folds, map/fmap, scans, sometimes explicit recursion, or perhaps the monad with do. What's the community feeling on this topic?

submitted by conklech
[link] [49 comments]
Categories: Incoming News