August 2015 - Haskell-Cafe

Type error depending on scope of pattern matching
by htebalaka 03 Aug '15

03 Aug '15

I'm curious if anyone can tell me why moving the pattern matching in these two examples makes it fail to compile, and what can be done to resolve the same issue in either of the latter two examples. As far as I can tell these should be equivalent. Unfortunately the solution used in the first examples won't work in the later ones due to the existential quantification. I've been asking on #haskell for a few days but haven't been able to find anyone who knows what the issue is. Code is available here: http://lpaste.net/137586 <http://lpaste.net/137586> -- View this message in context: http://haskell.1045720.n5.nabble.com/Type-error-depending-on-scope-of-patte… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

4 7

New Functional Programming Job Opportunities
by Functional Jobs 03 Aug '15

03 Aug '15

Here are some functional programming job opportunities that were posted recently: OCaml server-side developer at Ahrefs Research http://functionaljobs.com/jobs/8827-ocaml-server-side-developer-at-ahrefs-r… Cheers, Sean Murphy FunctionalJobs.com

1 0

Different forms for RandomT?
by Zemyla 03 Aug '15

03 Aug '15

Normally, a monad transformer to provide a random number generator would be of the form StateT g, where g is a RandomGen. But I've seen some libraries (like QuickCheck) define their RandomT as: newtype RandomT g m a = RandomT { runRandomT :: g -> m a } with their monadic bind operation defined as (RandomT m) >>= f = RandomT $ \g -> let (ga, gb) = split g in m ga >>= (\a -> runRandomT (f a) gb) and return and fail as in ReaderT. Can someone describe the advantages and disadvantages of doing RandomT this way? I mean, if your generator has a subpar split operation (and most do), this will obviously exacerbate any problems with it. Does it give any comparable advantages?

3 3

Annotated ASTs, and the tension between Bound, Free, and Cofree...
by Merijn Verstraaten 02 Aug '15

02 Aug '15

Hi, So I'm playing around with using bound to define a simple AST using the bound library to deal with substitution/abstraction. Being a lazy haskeller I figured that ASTs map nicely onto Free and that I could get all the necessary Applicative, Monad, etc. instances for free by using something like: newtype Expr a = Expr { unExpr :: Free (ExprF Expr) a } deriving (Functor,Applicative,Monad,Foldable,Traversable) data ExprF f a = App (f a) (f a) | Lam Type (Scope () f a) | TmTrue | TmFalse | If (f a) (f a) (f a) deriving (Eq,Ord,Show,Read,Functor,Foldable,Traversable) Now, for an AST to be useful, it has to be annotated with things like source location, type info, etc. So I started looking into how to accomplish this in a way where it's easy to add/modify annotations on any node of the AST. My initial idea was to use FreeT with ((,) a) as a base monad for annotations, but I quickly realised this fails, because "((,) a)" is only a Monad if 'a' is a Monoid and there's no sensible Monoid for type information/source locations. Then I looked around more and realised that this actually sounds a lot like Cofree. But here's where I run into problems. Bound expects the type of variables to be in the functor position of my Expr type, whereas Cofree expects the type of *annotations* to be in the functor position. So I can't figure out an elegant way to both use bound to deal with substitution for me *and* use Cofree to deal with annotations, since there's no way to make the types line up sanely. So my question boils down too: Has anyone done all the hard work for me already? i.e. how can I have an annotated AST with substitution *and* an easy way to modify the annotations, without writing a ton of boiler plate to deal with substitution and/or annotations? Cheers, Merijn

4 4

atomicity and visibility of readIORef / writeIORef
by Alexey Egorov 02 Aug '15

02 Aug '15

Hello haskellers, is there any guarantees of atomicity and visibility of read-write operations on IORefs, like Java have for volatile variables?

2 1

ANNOUNCE: Haskell Platform 7.10.2
by Mark Lentczner 01 Aug '15

01 Aug '15

Haskellers, we are pleased to announce the release of Haskell Platform 7.10.2 *get it here... <https://www.haskell.org/platform/>* Highlights include: - GHC 7.10.2 - packages & tools bumped to very latest - major package updates to: - attoparsec - case-insensitive - cgi - GLUT, GLURaw, OpenGL, & OpenGLRaw - mtl - network - primitive & vector - QuickCheck - random - syb - text - new website - new installer script for linux - 10 bugs closed: Issues · haskell/haskell-platform <https://github.com/haskell/haskell-platform/issues?utf8=%E2%9C%93&q=is%3Acl…> This is our first release concurrent with GHC's release. You'll notice that the version number has changed to reflect that from now on, our aim is to keep HP releases sync'd to GHC releases. *Note:* Haskell Platform download pages are often cached - you may need to hit reload to see the release. *About the last minute update to text package:* *tl;dr: Vast majority of code will never notice the difference. Go ahead and get the HP now and start enjoying 7.10.2 You can always update to the point release when it comes out.* Despite all the testing, GHC central noticed just a day before release that there was a regression with text literals in 7.10.2. It was possible to work around the issue via a change to the text package, and text-1.2.1.3 was released just today. Alas, there wasn't enough time to re-build and test the platform installers between then and now, so this release has text-1.2.1.1. There will be a point release (7.10.2.1) of the Platform this weekend or next with the updated text package. The issue does not result in incorrect code, only slow compilation times for very text literal laden code (as in thousands of literals), and slightly higher one-time construction cost at run-time. In full stack builds and many other test builds, these slow downs were inconsequential. *Windows Notes:* The Haskell Platform on Windows now provides the MSys2 tools. These tools are needed when installing packages that use conf-tools (generally rare). These tools are not automatically placed onto the PATH in order avoid troubles due to MSys2 tools which have the same name as a standard Windows tool (e.g., echo, find, dir). - Mark "release monad" Lentczner Special thanks to Erik Rantappa, Wasif Hasan Baig, & Ben Gamari for the new web site. Randy Polen for Windows build wrangling.

4 6