- Haskell-Cafe - Haskell.org

Trying to write an Embedded DSL that threads a monad?
by Oleg 17 Oct '15

17 Oct '15

> Ian Bloom wrote: > I've been hoping to design a domain specific embedded language in > Haskell that would let me pipe a commutative monad throughout an expression > written in the language. Special terms within the language will eventually > have access to this monad. Is there a reason tagless-final approach does not work for you? You can easily thread any monad, even if you don't make any provision for it initially. For example, http://okmij.org/ftp/tagless-final/index.html#call-by-any http://okmij.org/ftp/tagless-final/course/CBAny.hs uses monad to print out traces of the expression and then later to implement lazy evaluation for EDLS (which needs mutable cells).

2 2

Three open positions at Beautiful Destinations
by Tom Nielsen 16 Oct '15

16 Oct '15

The Data Science team at Beautiful Destinations is looking for three full-time developers and researchers with strong quantitative and programming skills. Beautiful Destinations ( http://www.beautifuldestinations.com/) is the world's largest travel influencer with a highly engaged audience of over 7 million followers across Instagram, Facebook and Snapchat. Beautiful Destinations distributes beautiful travel photography to its followers and helps clients to grow their social media channels. Our in-house photographers use drones and still photography to create content for our own accounts and our clients. The data science team has three aims: to predict and enhance the engagement of photographs on specific accounts; to measure influence on social media; and to determine the factors that contribute to the growth of social media accounts. Our internal API and core infrastructure are written in Haskell (using PostgreSQL), our Bayesian statistical time-series models use Stan ( http://mc-stan.org/) as well as some statistical models in Haskell. For image processing we use convolutional neural networks (in Python) and SIFT (C++/CUDA/Haskell). We are open to people bringing their preferred tools and maintain a polyglot environment. We are looking for developers who can fill the gap between data science and software engineering. We are at this stage only looking for full-time employees who can work in our London office. We welcome recent graduates and applicants with non-traditional backgrounds who show strong programming skills and capacity for independent learning. Please email contact(a)beautifuldestinations.com with any questions or with a CV if you are interested in this opportunity. -- <https://instagram.com/beautifuldestinations/>

1 0

Talk at tonight's Haskell Meetup at the Hacker Dojo.
by David Banas 16 Oct '15

16 Oct '15

Hi all, I plan to give a short talk, at tonight’s Haskell Meetup at the Hacker Dojo in Mountain View, CA, on using Conal’s Circat and Lambda-CCC machinery to implement the Fast Fourier Transform (FFT). Hope to see you there, -db

2 4

Specializing argument to forM_, mapM_ & foldM_ in base-4.8
by Amit Aryeh Levy 15 Oct '15

15 Oct '15

I've been running into a relatively small but frequent annoyance with base >= 4.8 (GHC 7.10). `Control.Monad.foldM_`, `Control.Monad.mapM_` and `Control.Monad.forM_` are generalized traverse over any `Foldable a` rather than just arrays (`[a]`). This is great, except I'm finding that, for a lot of my code that works well in previous versions, I need to specialize the argument to `[a]` now. If other people are encoutering a similar patter, I wonder what are your best practices for doing this: ScopedTypeVariables? Deconstruct the reconstruct the array? ... The most common example is when I deserialize a JSON array with aeson and want to traverse over that array (say, to store the objects to a DB): ``` let objArray = eitherDecode myjson case objArray of Left err -> ... Right (objs :: [MyObjType]) -> forM_ objs $ \obj -> saveToDb obj ``` The above fix requires `ScopedTypeVariables` (which is probably OK). Another option is to deconstruct and reconstruct the list: ``` Right (o:objs) -> forM_ (o:objs) $ \obj -> saveToDb obj ``` Does this get optimized away? Penny for your thoughts? Cheers! Amit

3 5

Trying to write an Embedded DSL that threads a monad?
by Ian Bloom 15 Oct '15

15 Oct '15

I've been wrestling with this for a while and I decided eventually to look for help. I've been hoping to design a domain specific embedded language in Haskell that would let me pipe a commutative monad throughout an expression written in the language. Special terms within the language will eventually have access to this monad. I've created a simplified version here to represent the main issues. Here is what I'd like from the language: * To use haskell syntax for substitution and pattern matching rather than implementing this myself. * To be able to express lambdas in my language. * To be able to embed any haskell terms including functions into the language. * I'd like the Haskell type checker to tell me about bad terms. * I'd like to thread a monad through the entire expression. So here is the first implementation that I tried of this (full source here: http://lpaste.net/142959) data Exp m x where Val :: m x -> Exp m x Lam1 :: m (a -> Exp m b) -> Exp m (a -> b) Lam2 :: m (a -> Exp m (b -> c)) -> Exp m (a -> b -> c) a function liftE allows me to lift a haskell term into an expression: liftE x = Val $ return x Application is a function <@> so: (<@>) :: forall m a b. Monad m => Exp m (a -> b) -> Exp m a -> Exp m b (<@>) (Val f) (Val x) = Val $ f `ap` x (<@>) (Lam2 f) (Val x) = Lam1 $ f >>= \f' -> x >>= \x' -> unLam1 $ f' x' (<@>) (Lam1 f) (Val x) = Val $ f >>= \f' -> x >>= \x' -> unVal $ f' x' Seems like it might work! In fact it does typecheck. So the first test expressions I'd like to try are these: mapE :: Monad m => Exp m ((a -> b) -> [a] -> [b]) mapE = Lam2 $ return $ \ f -> Lam1 $ return $ \ xxs -> case xxs of [] -> liftE [] (x:xs) -> liftE (:) <@> liftE (f x) <@> (mapE <@> liftE f <@> liftE xs) testExpression :: Monad m => Exp m [Int] testExpression = mapE <@> liftE (+10) <@> liftE [1,2,3,4] and just to justify doing any of this I'll create a Monad called BindCounter that counts the number of times bind is called: newtype BindCounter a = BC (Int -> (Int, a)) runBC (BC f) = f 0 instance Functor (BindCounter) where fmap f (BC x) = BC $ \t -> let (t', x') = x t in (t', f x') instance Applicative (BindCounter) where pure x = BC (\t -> (t,x)) f <*> x = f >>= \f' -> x >>= \x' -> return $ f' x' instance Monad (BindCounter) where return = pure BC f >>= g = BC $ \old -> let (new, val) = f (old + 1) BC f' = g val in f' new now I can try a test test = let (count, result) = runBC (unVal testExpression) in putStrLn $ "Count: " ++ show count ++ " Result: " ++ show result The result in ghci is: Count: 36 Result: [11,12,13,14] Ok so that's a lot. I was surprised I got this working. You can see from the code that my main gripe with this is I haven't found a way to remove the need to specify the number of embedded lambdas using Lam1 and Lam2 (we could easily add more) and I haven't found a way to apply a Lam to another Lam. I'm also curious if I am reinventing the wheel, I hadn't found a library yet that let's me do something similar.

3 3

Re: [Haskell-cafe] Talk at tonight's Haskell Meetup at the Hacker Dojo.
by David Banas 15 Oct '15

15 Oct '15

Yes, you may attend without being a member of the Hacker Dojo. -db On Thu, Oct 15, 2015 at 10:27 AM, Andrew Gibiansky < andrew.gibiansky(a)gmail.com> wrote: > Can I come if I'm not a member of Hacker Dojo? The website is unclear. > > -- Andrew > > On Thu, Oct 15, 2015 at 7:33 AM, David Banas <capn.freako(a)gmail.com> > wrote: > >> Hi all, >> >> I plan to give a short talk, at tonight’s Haskell Meetup at the Hacker >> Dojo in Mountain View, CA, on using Conal’s Circat and Lambda-CCC machinery >> to implement the Fast Fourier Transform (FFT). >> >> Hope to see you there, >> -db >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > >

1 0

ANN: stack-0.1.6.0
by Emanuel Borsboom 15 Oct '15

15 Oct '15

New version released of Stack, a build tool. See README <https://github.com/commercialhaskell/stack/tree/release#how-to-install> for installation and upgrade instructions. Major changes: - “stack setup” now supports building and booting GHCJS from source tarball. - On Windows, build directories no longer display “pretty” information (like x86_64-windows/Cabal-1.22.4.0), but rather a hash of that content. The reason is to avoid the 260 character path limitation on Windows. See #1027 <https://github.com/commercialhaskell/stack/pull/1027> - Rename config files and clarify their purposes #969 <https://github.com/commercialhaskell/stack/issues/969> - ~/.stack/stack.yaml → ~/.stack/config.yaml - ~/.stack/global → ~/.stack/global-project - /etc/stack/config → /etc/stack/config.yaml - Old locations still supported, with deprecation warnings - New command “stack eval CODE”, which evaluates to “stack exec ghc — -e CODE”. Other enhancements: - No longer install git on Windows #1046 <https://github.com/commercialhaskell/stack/issues/1046>. You can still get this behavior by running the following yourself: stack exec -- pacman -Sy --noconfirm git. - Typing enter during —file-watch triggers a rebuild #1023 <https://github.com/commercialhaskell/stack/pull/1023> - Use Haddock’s --hyperlinked-source (crosslinked source), if available #1070 <https://github.com/commercialhaskell/stack/pull/1070> - Use Stack-installed GHCs for stack init --solver #1072 <https://github.com/commercialhaskell/stack/issues/1072> - New experimental stack query command #1087 <https://github.com/commercialhaskell/stack/issues/1087> - By default, stack no longer rebuilds a package due to GHC options changes. This behavior can be tweaked with the rebuild-ghc-options setting. #1089 <https://github.com/commercialhaskell/stack/issues/1089> - By default, ghc-options are applied to all local packages, not just targets. This behavior can be tweaked with the apply-ghc-options setting. #1089 <https://github.com/commercialhaskell/stack/issues/1089> - Docker: download or override location of stack executable to re-run in container #974 <https://github.com/commercialhaskell/stack/issues/974> - Docker: when Docker Engine is remote, don’t run containerized processes as host’s UID/GID #194 <https://github.com/commercialhaskell/stack/issues/194> - Docker: set-user option to enable/disable running containerized processes as host’s UID/GID #194 <https://github.com/commercialhaskell/stack/issues/194> - Custom Setup.hs files are now precompiled instead of interpreted. This should be a major performance win for certain edge cases (biggest example: building Cabal itself <https://github.com/commercialhaskell/stack/issues/1041>) while being either neutral or a minor slowdown for more common cases. - stack test --coverage now also generates a unified coverage report for multiple test-suites / packages. In the unified report, test-suites can contribute to the coverage of other packages. Bug fixes: - Ignore stack-built executables named ghc #1052 <https://github.com/commercialhaskell/stack/issues/1052> - Fix quoting of output failed command line arguments - Mark executable-only packages as installed when copied from cache #1043 <https://github.com/commercialhaskell/stack/pull/1043> - Canonicalize temporary directory paths #1047 <https://github.com/commercialhaskell/stack/pull/1047> - Put code page fix inside the build function itself #1066 <https://github.com/commercialhaskell/stack/issues/1066> - Add explicit-setup-deps option #1110 <https://github.com/commercialhaskell/stack/issues/1110>, and change the default to the old behavior of using any package in the global and snapshot database #1025 <https://github.com/commercialhaskell/stack/issues/1025> - Precompiled cache checks full package IDs on Cabal < 1.22 #1103 <https://github.com/commercialhaskell/stack/issues/1103> - Pass -package-id to ghci #867 <https://github.com/commercialhaskell/stack/issues/867> - Ignore global packages when copying precompiled packages #1146 <https://github.com/commercialhaskell/stack/issues/1146>

1 0

Haskell developer job offer
by Vagif Verdi 14 Oct '15

14 Oct '15

https://home2.eease.adp.com/recruit2/?id=19008792&t=1 Email me if interested.

1 0

ghc-mod and IDE / plugin integration
by Alan & Kim Zimmerman 14 Oct '15

14 Oct '15

Historically ghc-mod provided (and still does) support for emacs and vim as part of its distribution. It is also used by a number of other IDE backends to provide a way of getting information about a project without worrying too much about the details of how the project is organised on the file system. There is currently a discussion between various interested parties about adjusting the way ghc-mod communicates with the IDE, to make it simpler to provide this support for other environments. This should end up with a definition of a protocol that ghc-mod can expose, which should also allow tools (such as HaRe) to be plugged into it, so that IDE integration can be handled by the various IDE integrators in a clean, common way. This is all just hand waving at the moment, so if anyone would like to get involved I am proposing that we revive the "Haskell IDE implementation"[1] google group/mailing list to host the discussion. The new design is/will be captured here [2] Regards Alan [1] https://groups.google.com/forum/#!forum/haskell-ide [2] https://github.com/kazu-yamamoto/ghc-mod/wiki/Library-API-Redesign

3 2

Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP
by Herbert Valerio Riedel 14 Oct '15

14 Oct '15

On 2015-10-06 at 10:10:01 +0200, Johan Tibell wrote: [...] >> You say that you stick to the 3-major-ghc-release support-window >> convention for your libraries. This is good, because then you don't need >> any CPP at all! Here's why: >> >> [...] >> > > So what do I have to write today to have my Monad instances be: > > * Warning free - Warnings are useful. Turning them off or having spurious > warnings both contribute to bugs. Depends on the warnings. Some warnings are more of an advisory kind (hlint-ish). I wouldn't consider redundant imports a source of bugs. Leaving off a top-level signature shouldn't be a source of correctness bugs either. Also, warnings about upcoming changes (i.e. deprecation warnings) also are not necessarily a bug, but rather a way to raise awareness of API changes. At the other end of the spectrum are more serious warnings I'd almost consider errors, such as failing to define a non-defaulting method or violating a MINIMAL pragma specification, as that can lead to bottoms either in the form of runtime errors or even worse, hanging computations (in case of cyclic definitions). IMO, GHC should classify its warnings into severities/categories or introduce some compromise between -Wall and not-Wall. > * Use imports that either are qualified or have explicit import lists - > Unqualified imports makes code more likely to break when dependencies add > exports. > * Don't use CPP. That being said, as how to write your Monad instances today with GHC 7.10 w/o CPP, while supporting at least GHC 7.4/7.6/7.8/7.10: This *does* work (admittedly for an easy example, but this can be generalised): --8<---------------cut here---------------start------------->8--- module MyMaybe where import Control.Applicative (Applicative(..)) import Prelude (Functor(..), Monad(..), (.)) -- or alternatively: `import qualified Prelude as P` data Maybe' a = Nothing' | Just' a instance Functor Maybe' where fmap f (Just' v) = Just' (f v) fmap _ Nothing' = Nothing' instance Applicative Maybe' where pure = Just' f1 <*> f2 = f1 >>= \v1 -> f2 >>= (pure . v1) instance Monad Maybe' where Nothing' >>= _ = Nothing' Just' x >>= f = f x return = pure -- "deprecated" since GHC 7.10 --8<---------------cut here---------------end--------------->8--- This example above compiles -Wall-clean and satisfies all your 3 stated requirements afaics. I do admit this probably not what you had in mind. But to be consistent, if you want to avoid unqualified imports at all costs in order to have full control of what gets imported into your namespace, you shouldn't tolerate an implicit unqualified wildcard `Prelude` import either. As `Prelude` can, even if seldom, gain new exports as well (or even loose them -- `interact` *could* be a candidate for removal at some point). > Neither AMP or MRP includes a recipe for this in their proposal. That's because -Wall-hygiene (w/o opting out of harmless) warnings across multiple GHC versions is not considered a show-stopper. In the specific case of MRP, I can offer you a Wall-perfect transition scheme by either using `ghc-options: -fno-mrp-warnings` in your cabal-file, or if that doesn't satisfy you, we can delay phase1 (i.e. redundant return-def warnings) to GHC 8.2: Now you can continue to write `return = pure` w/o GHC warning bothering you until GHC 8.2, at which point the 3-year-window will reach to GHC 7.10. Then starting with GHC 8.2 you can drop the `return` definition, and keep your More generally though, we need more language-features and/or modifications to the way GHC triggers warnings to make such refactorings/changes to the libraries -Wall-perfect as well. Beyond what Ben already suggested in another post, there was also the more general suggestion to implicitly suppress warnings when you explicitly name an import. E.g. import Control.Applicative (Applicative(..)) would suppress the redundant-import warning for Applicative via Prelude, because we specifically requested Applicative, so we don't mind that Prelude re-exports the same symbol. > AMP got one post-facto on the Wiki. It turns out that the workaround > there didn't work (we tried it in Cabal and it conflicted with one of > the above requirements.) Yes, that unqualified `import Prelude`-last trick mentioned on the Wiki breaks down for more complex imports with (redundant) explicit import lists. However, the Maybe-example above works at the cost of a wordy Prelude-import, but it's more robust, as you pin down exactly which symbol you expect to get from each module. > The problem by discussions is that they are done between two groups with > quite a difference in experience. On one hand you have people like Bryan, > who have considerable contributions to the Haskell ecosystem and much > experience in large scale software development (e.g. from Facebook). On the > other hand you have people who don't. That's okay. We've all been at the > latter group at some point of our career. [...] At the risk of stating the obvious: I don't think it matters from which group a given argument comes from as its validity doesn't depend on the messenger. Neither does it matter whether an argument is repeated several times or stated only once. Also, every argument deserves to be considered regardless of its origin or frequency. -- hvr

14 25