- Haskell-Cafe - Haskell.org

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

16 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 16 Oct '15

16 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 16 Oct '15

16 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 15 Oct '15

15 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

https://hackage.haskell.org/package/hoq build problems
by Vasili I. Galchin 14 Oct '15

14 Oct '15

Hello, I stumbled across hoq and it sounds very interesting to me. However, it has build problems now enumerated in the official build reports. I was thinking to investigate and possibly fix these build problems. However, when I run "cabal configure", I already ran into a problem: "unrecognized option `--extra-prog-path=/home/vasili/.cabal/bin'" I have been trying to track this down. Not sure how to fix this. Any help?? Regards, Vasily

4 5

[Announce] haskintex-0.6.0.0
by Daniel Díaz Casanueva 14 Oct '15

14 Oct '15

Dear Haskell users, I just released a new version of haskintex, the program that runs Haskell code inside LaTeX documents. http://hackage.haskell.org/package/haskintex # More about haskintex For those who don't know the program yet, _haskintex_ is a tool that executes Haskell code inside LaTeX documents, creating a new LaTeX document where each Haskell expression has been replaced by its result. Furthermore, since haskintex has a special command for using the HaTeX library, you will be able to write Haskell code that generates LaTeX code. Find more details in the haskintex documentation page: http://daniel-diaz.github.io/projects/haskintex # What's new? One of the main issues when evaluating Haskell code with haskintex was that haskintex was not aware of sandbox environments, so it had to rely on user or global package databases. From version 0.6.0.0, haskintex can now detect and use sandbox package databases, with no additional effort required from you. The -nosandbox flag has been added in case you still want the old behavior. Another addition is the -autotexy flag. Without the flag, every expression contained in a \hatex command is required to have type LaTeX. When the flag is enabled, this restriction is relaxed to any type that is an instance of the Texy typeclass. This typeclass contains instances for types that can be rendered to LaTeX syntax. Could be some text, numbers, or even matrices. You can create your own instances too. Suggestions, bugs, questions? Head to the haskintex issue tracker: https://github.com/Daniel-Diaz/haskintex/issues Happy texing, Daniel Díaz.

4 5

CFP: Workshop on Real World Domain Specific Languages, March 2016
by Simon Thompson 12 Oct '15

12 Oct '15

CALL FOR PAPERS ================================= Workshop on Real World Domain Specific Languages https://sites.google.com/site/realworlddsl In conjunction with The International Symposium on Code Generation and Optimisation 2016. http://cgo.org/cgo2016 Barcelona, 12-13 March, 2016 ================================= As the use of computers proliferates, the complexity and variety of systems continues to grow. As a result, it is becoming increasingly inflexible to "hard wire” behaviours into software. Software developers can enable more control over their software configurations by exploiting Domain Specific Languages (DSLs). Such DSLs provide a systematic way to structure the underlying computational components: to coin a phrase, a DSL is a library with syntax. There is an enormous variety of DSLs for a very wide range of domains. Most DSLs are highly idiosyncratic, reflecting both the specific natures of their application domains and their designers’ own preferences. This workshop will bring together constructors of DSLs for “real world” domains; that is, DSLs intended primarily to aid in building software to solve real world problems rather than to explore the more theoretical aspects of language design and implementation. We are looking for submissions that present the motivation, design, implementation, use and evaluation of such DSLs. ================================= Key Dates: ---------------- Paper submission deadline: 10 January 2016. Author notification: 2 February 2016. Final manuscript due: 21 February 2016. Workshop: 12-13 March 2016. ---------------- Submission Instructions: The EasyChair submission page for this workshop is https://easychair.org/conferences/?conf=rwdsl16 Accepted submissions will be published in the ACM Digital Library within its International Conference Proceedings Series. Submissions should be 8-10 in ACM double-column format. Authors should follow the information for formatting ACM SIGPLAN conference papers, which can be found at http://www.sigplan.org/Resources/Author. We will provide more details of the submissions format and process at the beginning of November. ================================= Program Chairs Rob Stewart, Heriot-Watt University Greg Michaelson, Heriot-Watt University PC Members Jost Berthold, Commonwealth Bank of Australia Andy Gill, University of Kansas Kevin Hammond, University of St Andrews Rita Loogen, Philipps Universitat Marburg Patrick Maier, University of Glasgow Josef Svenningsson, Chalmers University Simon Thompson, University of Kent Phil Trinder, University of Glasgow Contact Please email inquiries concerning the workshop to: R.Stewart(a)hw.ac.uk Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson(a)kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt

1 0

GHC 7.10.2 Stage 1 compiler
by Alexey Raga 12 Oct '15

12 Oct '15

Hello, On the "Download" page (https://www.haskell.org/ghc/download_ghc_7_10_2) I see the archive with the binaries for ARM. Unfortunately this archive doesn't seem to include stage 1 compiler (which would be a cross-compiler from x86 or x64 to ARM as far as I understand). I am trying to build one myself, but unfortunately no luck so far. Is it possible to know the detailed instructions on how the existing ARM package has been built? A script or a dockerfile would be ideal. I could tune that build and make a docker container that could cross-compile x64 -> ARM... Regards, Alexey.

1 0