November 2014 - Haskell-Cafe

Join a transformer
by Michael Snoyman 11 Apr '18

11 Apr '18

I'm wondering if this pattern exists and has a name. We have the concept of joining a Monad: join :: Monad m => m (m a) -> ma How about joining a monad transformer? joinT :: (Monad m, MonadTrans t) => t (t m) a -> t m a I believe implementing this in terms of MonadTransControl[1] might be possible, but I was wondering if there's an already existing idiom for this. Michael [1] http://haddocks.fpcomplete.com/fp/7.4.2/20130301-40/monad-control/Control-M…

5 5

PatternSignatures (rant)
by Johannes Waldmann 06 Apr '18

06 Apr '18

Dear all, (this is a rant - please ignore) why has "PatternSignatures" been renamed to "ScopedTypeVariables" (in ghc-6.10)? show me the alleged "type variable" in this code: do x :: Int <- [ 1 .. 10 ] ; return $ x^2 and why on earth do I need to use a language extension at all to get to the most basic thing of declarative programming: to declare the type of an identifier? This seriously hurts (me, at least) when teaching Haskell. Thanks - J.W.

4 4

possible bug in latest hackage Elf (Elf-0.27)
by Baojun Wang 18 Feb '17

18 Feb '17

Hi list, with below test program: -- /* test1.c: build with -g -O0 */ include <stdio.h> static const char appmsg[] = "hello, world"; int main(int argc, char* argv[]) { fputs(appmsg, stdout); return 0; } --- elf-test1.hs module Main where import qualified Data.ByteString as B import qualified Data.ByteString.Char8 as C import Control.Monad import Data.Elf testelf = "/tmp/test1" testelfsym = C.pack "appmsg" lookupSymbol1 _ [] = Nothing lookupSymbol1 sym (t:ts) = case (snd (steName t)) of Nothing -> lookupSymbol1 sym ts Just sname -> if sname == sym then Just t else lookupSymbol1 sym ts lookupSymbol _ [] = Nothing lookupSymbol sym (t:ts) = case (lookupSymbol1 sym t) of Nothing -> lookupSymbol sym ts t1 -> t1 test1 elf symtab symbol = mapM_ (print) (elfSections elf) test2 elf symtab symbol = lookupSymbol symbol symtab test3 elf symtab symbol = lookupSymbol symbol symtab >>= \et -> findSymbolDefinition et mainloop elf symtab symbol = -- (test1 elf symtab symbol) >> print (test2 elf symtab symbol) >> print (test3 elf symtab symbol) >> return () main = do contents <- B.readFile testelf let elf = parseElf contents symtab = parseSymbolTables elf mainloop elf symtab testelfsym --- the latest Data.Elf doesn't geive correct output as expected: output will be: Just (EST {steName = (9,Just "appmsg"), steEnclosingSection = Just (ElfSection {elfSectionName = ".fini", elfSectionType = SHT_PROGBITS, elfSectionFlags = [SHF_EXECINSTR,SHF_ALLOC], elfSectionAddr = 4195908, elfSectionSize = 9, elfSectionLink = 0, elfSectionInfo = 0, elfSectionAddrAlign = 4, elfSectionEntSize = 0, elfSectionData = "H\131\236\bH\131\196\b\195"}), steType = STTObject, steBind = STBLocal, steOther = 0, steIndex = SHNIndex 14, steValue = 4195924, steSize = 13}) >From above, you can see the steEnclosingSection is wrong and offset by 1. The *correct* output should be: Just (EST {steName = (9,Just "appmsg"), steEnclosingSection = Just (ElfSection {elfSectionName = ".rodata", elfSectionType = SHT_PROGBITS, elfSectionFlags = [SHF_ALLOC], elfSectionAddr = 4195920, elfSectionSize = 17, elfSectionLink = 0, elfSectionInfo = 0, elfSectionAddrAlign = 4, elfSectionEntSize = 0, elfSectionData = "\SOH\NUL\STX\NULhello, world\NUL"}), steType = STTObject, steBind = STBLocal, steOther = 0, steIndex = SHNIndex 14, steValue = 4195924, steSize = 13}) Just "hello, world\NUL" After check Elf.hs, I found there could be two issues: 1) in sectionByIndex, (SHNIndex) should start from 0, not 1; this cause the steEnclosingSection from my exmaple offset by 1; 2) in findSymbolDefinition, start should substract the sectionAddr (base address). please see below diff for details: -- --- a/Elf.hs 2012-12-04 19:27:51.000000000 -0800 +++ b/Elf.hs 2014-05-14 22:57:01.014498515 -0700 @@ -1,5 +1,5 @@ -- | Data.Elf is a module for parsing a ByteString of an ELF file into an Elf record. -module Data.Elf ( parseElf +module Elf ( parseElf , parseSymbolTables , findSymbolDefinition , Elf(..) @@ -666,12 +666,12 @@ getSymbolTableEntries e s = -- If the size is zero, or the offset larger than the 'elfSectionData', -- then 'Nothing' is returned. findSymbolDefinition :: ElfSymbolTableEntry -> Maybe B.ByteString -findSymbolDefinition e = - let enclosingData = fmap elfSectionData (steEnclosingSection e) - start = fromIntegral (steValue e) +findSymbolDefinition e = steEnclosingSection e >>= \enclosingSection -> + let enclosingData = elfSectionData enclosingSection + start = ( (fromIntegral (steValue e)) - (fromIntegral (elfSectionAddr enclosingSection) ) ) len = fromIntegral (steSize e) - def = fmap (B.take len . B.drop start) enclosingData - in if def == Just B.empty then Nothing else def + def = (B.take len . B.drop start) enclosingData + in if def == B.empty then Nothing else Just def runGetMany :: Get a -> L.ByteString -> [a] runGetMany g bs @@ -712,7 +712,7 @@ getSymbolTableEntry e strtlb = return $ EST (nameIdx,name) sec typ bind other sTlbIdx symVal size sectionByIndex :: Elf -> ElfSectionIndex -> Maybe ElfSection -sectionByIndex e (SHNIndex i) = lookup i . zip [1..] $ (elfSections e) +sectionByIndex e (SHNIndex i) = lookup i . zip [0..] $ (elfSections e) sectionByIndex _ _ = Nothing infoToTypeAndBind :: Word8 -> (ElfSymbolType,ElfSymbolBinding) -- Would you please check above change and update Data.Elf hackage? I cannot find the author from http://hackage.haskell.org/package/elf-0.27 Thanks baojun

14 19

Commutative monads vs Applicative functors
by Ronald Guida 09 Jul '16

09 Jul '16

I have a few questions about commutative monads and applicative functors. >From what I have read about applicative functors, they are weaker than monads because with a monad, I can use the results of a computation to select between alternative future computations and their side effects, whereas with an applicative functor, I can only select between the results of computations, while the structure of those computations and their side effects are fixed in advance. But then there are commutative monads. I'm not exactly sure what a commutative monad is, but my understanding is that in a commutative monad the order of side effects does not matter. This leads me to wonder, are commutative monads still stronger than applicative functors, or are they equivalent? And by the way, what exactly is a commutative monad?

6 6

ANNOUNCE: ioctl 0.0.1
by Maciej Piechotka 13 Sep '15

13 Sep '15

A package for type-safe I/O control. Currently only ioctl is supported. Currently simply a extract from my tuntap fork TODO: - Return the integer as well as structure (will break the API) - Port for Windows Network.Socket.IOCtl (as soon as I manage to setup some sane environment on this platform) - Wrapping around DeviceIoControl Example (in hsc): data NotRead = NotRead instance NotRead Int where ioctlReq _ = #const FIONREAD notRead s = ioctlsocket' s NotRead Regards

2 1

RFC: rewrite-with-location proposal
by Michael Snoyman 30 Mar '15

30 Mar '15

Quite a while back, Simon Hengel and I put together a proposal[1] for a new feature in GHC. The basic idea is pretty simple: provide a new pragma that could be used like so: error :: String -> a errorLoc :: IO Location -> String -> a {-# REWRITE_WITH_LOCATION error errorLoc #-} Then all usages of `error` would be converted into calls to `errorLoc` by the compiler, passing in the location information of where the call originated from. Our three intended use cases are: * Locations for failing test cases in a test framework * Locations for log messages * assert/error/undefined Note that the current behavior of the assert function[2] already includes this kind of approach, but it is a special case hard-coded into the compiler. This proposal essentially generalizes that behavior and makes it available for all functions, whether included with GHC or user-defined. The proposal spells out some details of this approach, and contrasts with other methods being used today for the same purpose, such as TH and CPP. Michael [1] https://github.com/sol/rewrite-with-location [2] http://hackage.haskell.org/packages/archive/base/4.6.0.1/doc/html/Control-E…

14 32

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

cabal keeps relinking
by Semen Trygubenko / Семен Тригубен ко 23 Jan '15

23 Jan '15

Dear Haskell-Cafe, cabal seems to be re-linking every time I run cabal build Wait was not an issue for small projects but for big ones it is starting to get in the way… How could I persuade cabal to re-link only if there are changes in the source tree and only these exes that require it? Many thanks, Semen PS I googled around and found this https://www.haskell.org/pipermail/libraries/2005-August/004306.html which seems to imply relink is (was?) conditional on multiple exes being present in the project. However, for me it was always relinking regardless. -- Семен Тригубенко http://trygub.com

2 6

Re: [Haskell-cafe] Yet Another Forkable Class
by oleg＠okmij.org 02 Jan '15

02 Jan '15

Perhaps effect libraries (there are several to choose from) could be a better answer to Fork effects than monad transformers. One lesson from the recent research in effects is that we should start thinking what effect we want to achieve rather than which monad transformer to use. Using ReaderT or StateT or something else is an implementation detail. Once we know what effect to achieve we can write a handler, or interpreter, to implement the desired operation on the World, obeying the desired equations. And we are done. For example, with ExtEff library with which I'm more familiar, the Fork effect would take as an argument a computation that cannot throw any requests. That means that the parent has to provide interpreters for all child effects. It becomes trivially to implement: > Another example would be a child that should not be able to throw errors as > opposed to the parent thread. It is possible to specify which errors will be allowed for the child thread (the ones that the parent will be willing to reflect and interpret). The rest of errors will be statically prohibited then. > instance (Protocol p) => Forkable (WebSockets p) (ReaderT (Sink p) IO) where > fork (ReaderT f) = liftIO . forkIO . f =<< getSink This is a good illustration of too much implementation detail. Why do we need to know of (Sink p) as a Reader layer? Would it be clearer to define an Effect of sending to the socket? Computation's type will make it patent the computation is sending to the socket. The parent thread, before forking, has to provide a handler for that effect (and the handler will probably need a socket). Defining a new class for each effect is possible but not needed at all. With monad transformers, a class per effect is meant to hide the ordering of transformer layers in a monad transformer stack. Effect libraries abstract over the implementation details out of the box. Crutches -- extra classes -- are unnecessary. We can start by writing handlers on a case-by-case basis. Generalization, if any, we'll be easier to see. From my experience, generalizing from concrete cases is easier than trying to write a (too) general code at the outset. Way too often, as I read and saw, code that is meant to be reusable ends up hardly usable.

9 12

ordNub
by Niklas Hambüchen 01 Jan '15

01 Jan '15

tldr: nub is abnormally slow, we shouldn't use it, but we do. As you might know, Data.List.nub is O(n²). (*) As you might not know, almost *all* practical Haskell projects use it, and that in places where an Ord instance is given, e.g. happy, Xmonad, ghc-mod, Agda, darcs, QuickCheck, yesod, shake, Cabal, haddock, and 600 more (see https://github.com/nh2/haskell-ordnub) I've taken the Ord-based O(n * log n) implementation from yi using a Set: ordNub :: (Ord a) => [a] -> [a] ordNub l = go empty l where go _ [] = [] go s (x:xs) = if x `member` s then go s xs else x : go (insert x s) xs and put benchmarks on http://htmlpreview.github.io/?https://github.com/nh2/haskell-ordnub/blob/1f… (compare `nub` vs `ordNub`). `ordNub` is not only in a different complexity class, but even seems to perform better than nub for very small numbers of actually different list elements (that's the numbers before the benchmark names). (The benchmark also shows some other potential problem: Using a state monad to keep the set instead of a function argument can be up to 20 times slower. Should that happen?) What do you think about ordNub? I've seen a proposal from 5 years ago about adding a *sort*Nub function started by Neil, but it just died. (*) The mentioned complexity is for the (very common) worst case, in which the number of different elements in the list grows with the list (alias you don't have an N element list with always only 5 different things inside).

23 49