- Haskell-Cafe - Haskell.org

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

04 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 04 Aug '15

04 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

digestive-functors and listOf
by Neil 01 Aug '15

01 Aug '15

I've been able to use digestive-functors with simple forms successfully in a snap application; however, I'm getting stuck when trying to handle a list of hidden inputs. There is something I'm not quite getting on how to use 'listOf'. Can anyone point me in the right direction? Thanks. The rendered html from a previous page includes the following hidden fields: <div id='messageForm.recipients' class='inputList'> <input type='hidden' name='messageForm.recipients.indices' value='0' /> <input type='hidden' id='messageForm.recipients.-1.email' name='messageForm.recipients.-1.email' value /> <input type='hidden' id='messageForm.recipients.0.email' name='messageForm.recipients.0.email' value='emai1l(a)email.com' /> <input type='hidden' id='messageForm.recipients.1.email' name='messageForm.recipients.1.email' value='email2(a)email.com' /> </div> The data types are: data ConfirmMessage = ConfirmMessage { isoDate :: T.Text, subject :: T.Text, body :: T.Text, action :: T.Text, recipients :: [Recipient]} deriving (Show) data Recipient = Recipient { email :: T.Text } deriving (Show) The forms are: messageForm :: (Monad m) => Form T.Text m ConfirmMessagemessageForm = ConfirmMessage <$> "isoDate" .: stringRead "Missing ISOdate" Nothing <*> "subject" .: stringRead "Subject required" Nothing <*> "body" .: stringRead "Body required" Nothing <*> "action" .: stringRead "Missing action" Nothing <*> "recipients" .: listOf recipientForm' Nothing recipientForm' :: (Monad m) => Formlet T.Text m RecipientrecipientForm'= Recipient <$> "email" .: stringRead "Missing email" Nothing Error message: Couldn't match type `Text.Digestive.Form.Internal.FormTree m0 v0 m0 Recipient' with `Maybe Recipient -> Form T.Text m Recipient' Expected type: Formlet T.Text m Recipient Actual type: Text.Digestive.Form.Internal.FormTree m0 v0 m0 Recipient Relevant bindings include recipientForm' :: Formlet T.Text m Recipient (bound at src/Handler/TradeNotifyConfirm.hs:224:1) In the expression: Recipient <$> "email" .: stringRead "Missing email" Nothing In an equation for `recipientForm'': recipientForm' = Recipient <$> "email" .: stringRead "Missing email" Nothing Thanks in advance, Neil

1 0

Taking over package erlang
by Poór Artúr 31 Jul '15

31 Jul '15

Hi, The package erlang (https://hackage.haskell.org/package/erlang) wasn't updated since 2008, and it became fairly outdated since then. The author was contacted half a year ago, but he didn't respond. So following the instructions on Hackage I state my intention to take over. I have made the package functional again, and I would like to make it available on Hackage. Artúr

2 1

New GHC fails to specialize imported function
by William Yager 31 Jul '15

31 Jul '15

Hello all, I just installed the new Haskell platform for OS X. It seems to have caused a major performance regression for a program I'm working on, making it well over 25x slower. The culprit appears to be that the new GHC (7.10.2) fails to specialize an imported function. If I manually add a SPECIALIZE pragma, performance goes back to around what it used to be. The code in question is located at https://github.com/wyager/HNet . As it stands, the code takes about 30 seconds to run on my machine. With the previous haskell-platform, it only took about .9 seconds. If I modify Operations.hs and uncomment the SPECIALIZE pragma, runtime goes down to about 1.1 seconds (still slower for some reason, but not awful). To test, compile with -O2 (as the program makes heavy use of Data.Vector, which requires -fspec-constr for performance). Additionally, my experience doesn't seem to match https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/pragmas.html… in that if I add an INLINABLE pragma at the site of (••)'s definition and then try to SPECIALIZE it in a different file after importing, GHC tells me "Warning: SPECIALISE pragma on INLINE function probably won't fire: ‘••’". Cheers, Will

2 1

Excessive whitespace with tasty all of a sudden
by Rogan Creswick 31 Jul '15

31 Jul '15

I recently have been refactoring chatter, and finally got the test suite semi-operational (after lots of extensive changes, both to the library and to the tests to add tests and to make them compatible with the new APIs). Somewhere during the changes, the whitespace output by tasty to format the test status lines nicely has grown out of hand. For example, tests that used to show the OK message on the same line, now look like this (see below). Has anyone else run across this? Does anyone have debugging suggestions? Thanks! Rogan NLP.POS.LiteralTagger Empty tagger always tags as UNK: OK +++ OK, passed 100 tests. Initial training Simple training test: OK Duplicate entries -- use the last value.: OK

1 0