October 2016 - 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

Source code location in IO?
by Tom Ellis 30 Jun '17

30 Jun '17

Is it compatible with the semantics of Haskell to have a function sourceLocation :: IO String which when run returns the source file location at which it is used? For example, suppose Main.hs is module Main where main = do putStrLn =<< sourceLocation putStrLn "Hello" putStrLn =<< sourceLocation It would print the following when run Main.hs:4 Hello Main.hs:6 and module Main where main = do let s = sourceLocation putStrLn =<< s putStrLn "Hello" putStrLn =<< s It would print the following when run Main.hs:4 Hello Main.hs:4 If this is not compatible with the semantics of Haskell, why not? I agree that the two programs must have the same denotation, but is there anything that requires them to have the same output when run? Tom

6 7

Why is Megaparsec treating these two operators differently?
by Jeffrey Brown 14 May '17

14 May '17

I used Text.Megaparsec.Expr to write a minimal (56 lines) 2-operator recursive parser. It's on github[1]. It outputs a binary tree of the following form: data AExpr = Var String | Pair AExpr AExpr deriving (Show) The operator table supplied to makeExprParser defines two operators, # and ##. ## binds after #, but both of them refer to the same function, the Pair constructor of the AExpr data type: aOperators :: [[Operator Parser AExpr]] aOperators = [ [ InfixN # symbol "#" *> pure (Pair) ] , [ InfixN # symbol "##" *> pure (Pair) ] ] The # operator works in isolation: > parseMaybe aExpr "a # b" Just (Pair (Var "a") (Var "b")) Parentheses work with the # operator: > parseMaybe aExpr "(a # b) # (c # d)" Just (Pair (Pair (Var "a") (Var "b")) -- whitespace added by hand (Pair (Var "c") (Var "d"))) And the # and ## operators work together as intended: > parseMaybe aExpr "a # b ## c # d" Just (Pair (Pair (Var "a") (Var "b")) -- whitespace added by hand (Pair (Var "c") (Var "d"))) But the ## operator in isolation does not parse! > parseMaybe aExpr "a ## b" Nothing [1] https://github.com/JeffreyBenjaminBrown/digraphs-with-text/blob/master/howt… -- Jeff Brown | Jeffrey Benjamin Brown Website <https://msu.edu/~brown202/> | Facebook <https://www.facebook.com/mejeff.younotjeff> | LinkedIn <https://www.linkedin.com/in/jeffreybenjaminbrown>(I often miss messages here) | Github <https://github.com/jeffreybenjaminbrown>

3 6

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

A Procedural-Functional Language (WIP)
by Rik Howard 12 Dec '16

12 Dec '16

Dear Haskell Cafe Subscribers on the recommendation of someone for whom I have great respect, I have just subscribed to this list, it having been suggested as being a good place for me to get feedback regarding a project that I have been working on. I am humbled by the level of discussion and it feels to be a very bold step for me to request anybody's time for my words. The linked document is a four-page work-in-progress summary: the length being stipulated, potential novelty being the other main requirement. Given the requirements, the summary necessarily glosses over some details and is not yet, I fear, completely correct. The conclusion is, more or less, the one at which I am aiming; the properties are, more or less, the ones that are needed. http://www.dcs.bbk.ac.uk/~rik/gallery/work-in-progress/document.pdf The work arises from an investigation into functional programming syntax and semantics. The novelty seems to be there but there is too a question as to whether it is simply a gimmick. I try to suggest that it is not but, by that stage, there have been many assumptions so it is hard to be sure whether the suggestion is valid. If anyone has any comments, questions or suggestions, they would be gratefully received. Yours sincerely Rik Howard

15 36

memory leak when using "forever"
by Zoran Bosnjak 04 Nov '16

04 Nov '16

Hello all, can you please explain why does this simple program leak memory. But, if I replace loop2 with loop1 (that is: without using "forever"), then it does not leak. Is this a problem in "forever" implementation or am I misusing this function? In the sources of base: http://hackage.haskell.org/package/base-4.9.0.0/docs/src/Control.Monad.html… ... there is some mention of memory leak prevention, but it looks like something is not right in this case. import Control.Concurrent import Control.Monad import Control.Monad.Trans import Control.Monad.Trans.Reader import Control.Monad.Trans.State main :: IO () main = do --let loop1 = (liftIO $ threadDelay 1) >> loop1 let loop2 = forever (liftIO $ threadDelay 1) _ <- runStateT (runReaderT loop2 'a') 'b' return () regards, Zoran

2 3

GHCJS Bad first impression
by Zachary Kessin 02 Nov '16

02 Nov '16

I am starting a project that might use ghcjs and it seems to me that if someone's first impression of it is tying stack install and having it take several hours to build everything that is not a very welcoming way to get people to use ghcjs. Why not precompiled binaries? Also while It has been compiling i have seen a lot of warnings? Zach -- Zach Kessin SquareTarget <http://squaretarget.rocks?utm_source=email-sig> Twitter: @zkessin <https://twitter.com/zkessin> Skype: zachkessin ᐧ

5 7

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 158, Issue 29
by Rik Howard 02 Nov '16

02 Nov '16

Richard thanks for your response and the references which I'll look into, the Dijkstra sounds particularly relevant. "Procedural-functional" is not novel; and as you also mentioned, Haskell, Clean and Mercury would qualify, if you chose to look at it that way, as would other languages. Any novelty in the note would only ever be in the way that the mix is provided. You raise salient points about the sort of challenges that languages will need to confront although a search has left me still unsure about PGPUs. Can I ask you to say a bit more about programming styles: what Java can't do, what others can do, how that scales? Regards Rik On 27 October 2016 at 13:00, <haskell-cafe-request(a)haskell.org> wrote: > Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request(a)haskell.org > > You can reach the person managing the list at > haskell-cafe-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > > > Today's Topics: > > 1. Re: A Procedural-Functional Language (WIP) (Rik Howard) > 2. Re: A Procedural-Functional Language (WIP) (Rik Howard) > 3. Re: A Procedural-Functional Language (WIP) (Richard A. O'Keefe) > 4. Proof of concept of explanations for instance resolution > (Michael Sloan) > 5. Re: A Procedural-Functional Language (WIP) (Joachim Durchholz) > 6. Re: Proof of concept of explanations for instance resolution > (Tom Ellis) > 7. Fwd: How to best display type variables with the same name > (Christopher Done) > 8. CoALP-Ty'16: Call for Participation (František Farka) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 26 Oct 2016 16:48:47 +0100 > From: Rik Howard <rik(a)dcs.bbk.ac.uk> > To: Joachim Durchholz <jo(a)durchholz.org> > Cc: haskell-cafe(a)haskell.org > Subject: Re: [Haskell-cafe] A Procedural-Functional Language (WIP) > Message-ID: > <CAAGBjQW+xzaU5kGQsm5S_et6v4YXOZ1QvkNN_cRfigRUOdbNMQ@ > mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Jo > > > > Question is not whether these things are precluded, question is how you > > want to tackle them. It's not even stating design goals here. > > > The section on Types has been amended to note that these questions form a > part of the ongoing work. > > > > > > > The salient point of this and some other features is that they make it > > easier to reason about a given program's properties, at the expense of > > making programming harder. > > > > You put that point well. > > > > > > The basic concept of subtypes is simple, but establishing a definition of > > "subtype" that is both useful and sound is far from trivial. > > > > I hope that there is nothing that I've said that could be interpreted as me > thinking otherwise. As you mentioned elsewhere, though, they look too > appealing to ignore. > > > > > > For example. mutable circles and mutable ellipses are not in a subtype > > relationship to each other if there is an updating "scale" operation with > > an x and y scaling factor (you cannot guarantee that a scaled circle > stays > > circular). > > The design space for dealing with this is far from fully explored. > > > > I'm not sure that the language could support mutable structures but I take > your point that there are complications. > > > > > > Also, subtypes and binary operators do not really mix; google for > > "parallel type hierarchy". (The core of the problem is that if you make > > Byte a subtype of Word, declaring the (+) operator in Word as Word -> > Word > > will preclude Byte from being a subtype because you want a covariant > > signature in Byte but that violates subtyping rules for functions. So you > > need parametric polymorphism, but now you cannot use the simple methods > for > > subtyping anymore.) > > > Clearly there is more to be done in this area. > > > > > > The key point to mention is that you want to maintain referential > > integrity. > > > > The document now mentions this. > > > > > > Sounds pretty much like the conseqences of having the IO monad in > Haskell. > > > > That seems fair to me although the broader impact on an entire program > would be different I think. > > > > > > I think you should elaborate similarities and differences with how > Haskell > > does IO, that's a well-known standard it is going to make the paper > easier > > to read. Same goes for Clean&Mercury. > > > Something like that is addressed in Related Work. Clean is already on the > list but it sounds, from your comments and those of others, as if Mercury > may be worth including as well. > > > > > > It's hard to tell whether it is actually new, too many details are > missing. > > > Certainly you have spotted the vagueness in the types however I think that > that issue can be momentarily set aside from the point of view of novelty. > The language is purely functional with respect to functions and provides > out-vars as the only mechanism for dealing with IO. Let's assume for the > moment that that all hangs together: if there is another language that does > that, no novelty; otherwise, there is novelty. > > Once again, your feedback has been useful and stimulating. Many thanks! > > Regards > Rik >

3 10

PSA: gcc-6.2.0 breaks linking in ghc 7.10.3/8.0.1
by Alan & Kim Zimmerman 31 Oct '16

31 Oct '16

On my Debian testing machine, after gcc updated to gcc (Debian 6.2.0-9) 6.2.0 20161019 I started getting linker errors complaining about -fPIC Herbert Valerio Riedel pointed out on #hackage that the settings file has to be updated to cope with this. So, the files /opt/ghc/7.10.3/lib/ghc-7.10.3/settings /opt/ghc/8.0.1/lib/ghc-8.0.1/settings need to be updated to have the following values set ("C compiler flags", "-fno-PIE -fno-stack-protector"), ("C compiler link flags", "-no-pie"), ("ld flags", "-no-pie"), The precise location of these files may differ on your machine. Alan

2 1