- Haskell-Cafe - Haskell.org

hflags
by Maurizio Vitale 07 Feb '15

07 Feb '15

with ghc 7.8.4 and hflags 0.4 the following program: {-# LANGUAGE TemplateHaskell #-} module Main where import HFlags defineFlag "f" True "A flag." --defineFlag "g" True "Another flag." main = do _ <- $initHFlags "flags demo" print Main.flags_f gives me a runtime error about the flag f not being found, unless I add the declaration of a second flag. It seems like the last flag definition is not seen. Any idea/suggestion? Thanks, Maurizio

3 3

Re: [Haskell-cafe] recursion problem part 2
by Roelof Wobben 06 Feb '15

06 Feb '15

1 0

Re: [Haskell-cafe] recursion problem part 2
by Roelof Wobben 06 Feb '15

06 Feb '15

Dmitry Olshansky schreef op 6-2-2015 om 16:25: > toDigits :: Integer -> [Integer] > toDigits n > | n < 0 = [] > | n < 10 = [n] > | otherwise = toDigits (n `div` 10) ++ [n `mod` 10] > Thanks that worked, I have now to figure out why I see [0] on 0 and no zero when it reaches it end-point. isDigits 0 n< 10 so [0] IsDigits 1 n < 0 not true n < 10 not true. toDigits 1 ++ [0] toDigits 1 + [0] n< 0 not true n < 10 true so [1] ++ [0] [1] ++ [0] is [1.0] where the output is [1] So somehow I do not understand fully how this works . Roelof

1 0

recursion problem part 2
by Roelof Wobben 06 Feb '15

06 Feb '15

Hello, I partly solved the problem of cis194 of turning 123 into [1,2,3] But I ran into a problem I cannot solve . When I have this : toDigits :: Integer -> [Integer] toDigits n | n < 0 = [] | n == 0 = [] | otherwise = toDigits (n `div` 10) ++ [n `mod` 10] toDigits 123 gives [ 1,2,3] but toDigits 0 gives [] where I expect to be [0] So I change the code to this : toDigits :: Integer -> [Integer] toDigits n | n < 0 = [] | n == 0 = [0] | otherwise = toDigits (n `div` 10) ++ [n `mod` 10] Now toDigits 0 gives [ 0] but toDigits 123 gives now [ 0, 1 ,2, 3] where I expect to be [1,2,3] Can someone give me a tip how to solve this I have asked this on the beginners ML but the only answer I get was someone who was using some if -then statement and I think I can be solved without. Roelof

2 1

error compiling 24 Days of Hackage: heist
by hokum 06 Feb '15

06 Feb '15

Hello, I was trying to compile an example of heist (a template engine) usage from 24 Days of Hackage: heist, but ended up with an error message: src/Main.hs:60:7: `hcTemplateLocations' is not a record selector In the first argument of `initHeist', namely `mempty {hcTemplateLocations = [loadTemplates "templates"], hcInterpretedSplices = defaultInterpretedSplices}' In a stmt of a 'do' block: heist <- initHeist (mempty {hcTemplateLocations = [loadTemplates "templates"], hcInterpretedSplices = defaultInterpretedSplices}) In the second argument of `($)', namely `do { heist <- initHeist (mempty {hcTemplateLocations = [loadTemplates "templates"], hcInterpretedSplices = defaultInterpretedSplices}); Just (output, _) <- renderTemplate heist "billy"; liftIO . BS.putStrLn . toByteString $ output }' src/Main.hs:61:7: `hcInterpretedSplices' is not a record selector In the first argument of `initHeist', namely `mempty {hcTemplateLocations = [loadTemplates "templates"], hcInterpretedSplices = defaultInterpretedSplices}' In a stmt of a 'do' block: heist <- initHeist (mempty {hcTemplateLocations = [loadTemplates "templates"], hcInterpretedSplices = defaultInterpretedSplices}) In the second argument of `($)', namely `do { heist <- initHeist (mempty {hcTemplateLocations = [loadTemplates "templates"], hcInterpretedSplices = defaultInterpretedSplices}); Just (output, _) <- renderTemplate heist "billy"; liftIO . BS.putStrLn . toByteString $ output }' It's probably something to do with lenses, but I'm not very familiar with it. Four hours of googling didn't give me anything on the subject, so any help? Here is the code(in the state I left it): module Main ( main ) where import Blaze.ByteString.Builder (toByteString) import qualified Data.ByteString.Char8 as BS import Control.Monad.IO.Class (MonadIO(..)) import Control.Monad.Trans.Either import Data.Monoid (mempty) import Data.Foldable (forM_) import Heist import Heist.Interpreted import Text.XmlHtml (Node(TextNode), renderHtmlFragment, Encoding(UTF8)) billy :: IO () billy = eitherT (putStrLn . unlines) return $ do heist <- initHeist mempty { hcTemplateLocations = [ loadTemplates "templates" ] , hcInterpretedSplices = defaultInterpretedSplices } Just (output, _) <- renderTemplate heist "billy" liftIO . BS.putStrLn . toByteString $ output main = do putStrLn "---"

2 1

Domain specific error messages
by Sean Seefried 06 Feb '15

06 Feb '15

If the list doesn't mind I'm reposting my reply to Alberto G. Corona in under the thread "Monads: external questions" as a new message since the topic has changed enough. ------------- Hi Alberto, I've been interested in domain specific error messages for years and I agree with you that it is one of the major things holding back the utility of DSLs to novice programmers. This is a shame since one of the touted benefits of DSLs is that they *can* be used by novices with a minimum of training, which is simply not true in the presence of error messages that require detailed knowledge of Haskell to understand. I'd caution against saying that there is a lack of interest in that ticket you linked to. It's still a research level problem despite the fact that some great work has been done on it already. Incidentally, the author of "Scripting the Type Inference Process" went on to do an entire PhD on the topic entitled "Top Quality Type Error Messages"[2]. I recently wrote him an email and he told me that the constraint-based type inference framework that he used in the thesis, TOP, is available on Hackage [3]. Recently I noticed that this problem is already being worked on in Idris. See "Reflect on your Mistakes!" [4] and some code on GitHub [5]. Perhaps we can get people interested in this feature again? Cheers, Sean [1] http://www.open.ou.nl/bhr/heeren-scripting.pdf [2] http://www.open.ou.nl/bhr/TopQuality.pdf [3] https://hackage.haskell.org/package/Top [4] http://www.itu.dk/people/drc/drafts/error-reflection-submission.pdf [5] https://gist.github.com/david-christiansen/8349698 On Sun Nov 23 2014 at 3:57:10 AM Alberto G. Corona <agocorona(a)gmail.com> wrote: > Michael: > > You are right, but these are minor problems I think, compared with the > huge potential advantages. > > I can not believe it when a slow immature language like Ruby could take > over web development just for one library, Rails and some buzzwords, when a > faster, safer language can do it millions of times better. Haskell can > revolutionize all the industry simply selling it not as one more language, > but as THE meta-language for building EDSLs for each domain problem. some > EDSLs so close to the domain problem that can be used by non-programmers. > > That lack of vision and effort in the side of the haskell community hurts > me. And the lack of interest in this ticket > > https://ghc.haskell.org/trac/ghc/ticket/7870 > > Is a clear display of this lack of interest. it is like the Aristocracy > of the Haskell Wondwerland fears to be hijacked by hordes of mediocre DSL > villains from the industry, so it is necessary to keep the walls high > > Haskell is a language dominated by academics that has no interest in the > success of Haskell. On the contrary. > > 2014-10-29 15:13 GMT+01:00 Michael Jones <mike(a)proclivis.com>: > >> When I took a Lambda Calculus class years ago in Silicon Valley, 90% of >> the students groaned and complained. They just wanted to learn Java and >> make money. Having a background in OO design and experience with Eiffel, I >> was intrigued and stuck with it, building some tools with ML, and later >> Haskell. >> >> In the workplace it was near impossible to avoid the .Net culture, and >> most of my code has been C#. But the factors that mattered were: >> >> - Continuity with past languages and tools >> - Availability of programmers >> - Third party libraries >> - Inter langage operability >> - Reuse of legacy code >> >> etc >> >> Best I can tell, there is no way to avoid the business context. I suggest >> that if you have freedom, you need to be multilingual. Many systems could >> benefit from applying the proper tool to the corresponding problem. >> >> But I will say this, becoming proficient at Haskell really improved my >> designs by providing an alternative conceptual framework. But, it had a >> very substantial learning curve. All I can say is trust that even if your >> core language is procedural, you will be better at that for learning a >> functional language. >> >> To make Haskell a first class citizen in the IT shops, I think focus >> would have to shift more to the business context and needs. And certainly >> more focus in the universities that are still dominated by procedural >> languages. Once that is drilled into ones head, it affects the way one >> thinks. >> >> To give an example, I have these problems: >> >> - Update to GHC 7.8.3 from 7.6 caused run time behavior changes breaking >> USB application >> - Sandboxes are not completely isolated from the core library and often >> builds break >> - Most new grads don’t even know what a functional language is >> - Documentation gets out of sync with releases (where documentation means >> Wiki and web) >> - FFI is difficult to use and debug >> - Lack of books, user groups, etc >> >> Mike >> >> On Oct 29, 2014, at 3:48 AM, Alberto G. Corona <agocorona(a)gmail.com> >> wrote: >> >> I know that I'm using a different language when talking about monads. The >> language of the IT industry. >> >> Many haskellers use the language for toy programming. Others are >> professional academics. The few that use the language for commercial >> purposes are too busy developing practical applications rather than >> thinking deep about how to apply the haskell concepts to their problems. >> As a result many of such problems remains essentially unsolved. These busy >> developers try to transcode solutions from other languages that lack the >> deep and expressiveness of Haskell. >> >> This lack of interest in one side and the lack of time in the other is >> disappointing. The symptoms are everywhere. Particularly, I find it in the >> lack of support and interests for this ticket: >> >> https://ghc.haskell.org/trac/ghc/ticket/7870 >> >> I though that there was definitively a shift from "avoid success at all >> costs" a few years ago, for a commitment for the success, but still there >> are many minds to change, especially the brilliant ones. >> >> 2014-10-26 2:02 GMT+01:00 Alberto G. Corona <agocorona(a)gmail.com>: >> >>> >>> >>> 2014-10-26 1:23 GMT+02:00 Jeffrey Brown <jeffbrown.the(a)gmail.com>: >>> >>>> As opposed to the internal logic of monads, how they work, I hope to >>>> start a discussion about their external logic: how and why to use monads. >>>> >>>> design >>>> ------ >>>> How do monads change the way one >>>> * thinks about a problem? >>>> * structures data? >>>> * refactors? >>>> * tests? >>>> Should I always be giving the monads a lot of cognitive bandwidth, >>>> because they reorder the way everything should be, or is it an investment >>>> with a high initial cognitive cost but requiring little maintenance >>>> thereafter? >>>> >>>> what is their common framework? >>>> ------------------------------- >>>> Monads let data reach farther than it otherwise would. Subjectively, >>>> they feel like a controlled way of violating encapsulation. >>>> >>>> Are there other, deeper or more specific, commonalities that explain >>>> why monads are a good way to implement exceptions, output, state, and >>>> perhaps other services? >>>> >>> >>> I made monads for execution state recovery, web navigation.. workflows, >>> long running transactions, backtracking, traceback and event chaining in >>> web browser applications. >>> >>> I´m confident that the perspectives for monads to solve real IT problems >>> are very promising. And when I mean monad I mean all the associated stuff : >>> applicative, alternative etc. >>> >>> I´m confident that there will be a cloud monad (for chaining jobs and >>> work distribution) an orchestration monad for orchestration of web services >>> etc. >>> >>> There are problems that are intrinsically procedural among them, almost >>> all problems in IT. instead of using ad-hoc data/control structures like >>> events, handlers, configurations, routes, exceptions, logs, transaction >>> compensations, promises ....the list goes on and on , the monad is the >>> common control structure that can subsume all of them inside his >>> programmable semicolon >>> >>> So, once the monad is set up, the user of the monad code the solution >>> for the domain problem in a clean EDSL with absolutely no plumbing, at the >>> level of the problem. so anyone that know the problem can understand the >>> code. >>> >>> Is the monad instance, and the applicative etc the ones that subsume >>> under the hood the special data/control structure necessary for the domain >>> problem. >>> >>> >>> Often if your code is general enough, it can be used in any monad. So >>> you benefit from this. I think that in th future there will be a lot of >>> surprises about the shareability of code between monads when the IT >>> industry start to use them seriously. I think that we are just at the >>> beginning. >>> >>> I hope that some others of your questions are also answered here >>> >> >> >> >> -- >> Alberto. >> >>

11 19

Are conditional changes in library interfaces problematic?
by Adam Bergmark 06 Feb '15

06 Feb '15

transformers 0.4 deprecated ErrorT in favor of ExceptT. I've noticed that several packages use CPP to conditionally add ExceptT instances, like this: ``` #if MIN_VERSION_transformers(0,4,0) instance C m => C (ExceptT e m) where #endif ``` The problem I've found with this is that I will get a different interface depending on which transformers version is picked. There is a transformers-compat[1] library that provides ExceptT when using older versions of transformers, when combining these I end up with a compilation failure since the ExceptT instances are no longer included due to CPP. The alternatives I see are: 1. Use transformers-compat (and as of today mtl-compat[2]) 2. Drop support of older versions of dependencies 3. Advise against compat packages The first alternative seems preferable from a user's standpoint. For transformers and mtl I argue it's the most pragmatic option. I think the compat packages are a good thing, especially for core packages, since they let us maintain backwards compatibility. Do you agree with this line of thought? I started working on pull requests to "fix" this but I'd appreciate feedback on the issue first. Along these lines, does conditionally altering the interface of a package like this violate the PVP? Cheers, Adam [1] http://hackage.haskell.org/package/transformers-compat [2] http://hackage.haskell.org/package/mtl-compat

1 0

ghci on ARM m3?
by Mike Meyer 06 Feb '15

06 Feb '15

Lately, I've not been doing much Haskell because I've buried in embedded systems work. The code is all C, with only a smidgen of C++ (for which I am grateful). One of the things I've been toying with is turning part of the on-chip configuration information a haskel functions. They'd even be pure code, and would be a lot more expressive than what's there now. The target platforms are running Cortex M3 CPUs. I know that jhc/ajhc will generate code for those CPUs, but I really need at least a subset of the compiler running on the target processor with no pre-installed RTOS. Has that been done? Is it likely to even be possible? As part of the project, I'll need to install both a cross-compiler on my Unix box, and the the compiler (or parts of it) on the M3. Can someone provide pointers to tutorials on that? My google-foo wasn't powerful enough to find any. I'm thinking about using either an Aruino Due (as it has the M3 CPU on it) as a testbed platform. So tutorials targeted for that platform would be particularly appreciated. Since I hopefully have the eyes of people experienced with these things, should I be considering a raspberry pi or something similar instead of the Due? Basically, will I be able to run code built for the M3 CPU on the pi CPUs? thanks, Mike

4 3

ANNOUNCE: bash script for haskell
by James Crayne 06 Feb '15

06 Feb '15

I'm sure variations of this exist, but for some reason I didn't find any while searching, so I made my own. The idea is for using haskell on the command line instead of perl or awk etc. https://github.com/jimcrayne/hk

5 6

ANNOUNCE: UISF Release
by Daniel Winograd-Cort 06 Feb '15

06 Feb '15

I'm happy to announce the release of UISF on Hackage! http://hackage.haskell.org/package/UISF UISF provides an arrowized FRP library for graphical user interfaces. It stems from work done on Euterpea (http://haskell.cs.yale.edu/euterpea/) and is built atop GLFW. One of the neat things about UISF is how it behaves with ArrowChoice. Specifically, one can create dynamic arrows so long as they are *predictably* dynamic. This means that it is possible to have widgets activate, deactivate, and even replicate without resorting to switch. If you're interested in playing around with it, feel free to take a look at the example files, some of which are pretty well documented (note that there are more than just the two displayed on the hackage page). Do let us know about comments you have and bugs you find. -Daniel

1 0