- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] StableNames and monadic functions
by Ismael Figueroa Palet 26 Jun '12

26 Jun '12

Thanks Lorenzo, I'm cc'ing the list with your response also: As you point out, when you do some kind of "let-binding", using the where clause, or explicit let as in: main :: IO () main = do let f1 = (successor :: Int -> State Int Int) let f2 = (successor :: Int -> Maybe Int) b2 <- eq f2 f2 b1 <- eq f1 f1 print (show b1 ++ " " ++ show b2) The behavior is as expected. I guess the binding triggers some internal optimization or gives more information to the type checker; but I'm still not clear why it is required to be done this way -- having to let-bind every function is kind of awkward. I know the details of StableNames are probably implementation-dependent, but I'm still wondering about how to detect / restrict this situation. Thanks 2012/6/26 Lorenzo Bolla <lbolla(a)gmail.com> > From StableName docs: > >> The reverse is not necessarily true: if two stable names are not equal, >> then the objects they name may still be equal. > > > This version works as expected: > > import System.Mem.StableName > import Control.Monad.State > > eq :: a -> b -> IO Bool > eq a b = do > pa <- makeStableName a > pb <- makeStableName b > return (hashStableName pa == hashStableName pb) > > successor :: (Num a, Monad m) => a -> m a > successor n = return (n+1) > > -- main :: IO () > -- main = do > -- b2 <- eq (successor :: Int -> State Int Int) (successor :: Int > -> State Int Int) > -- b1 <- eq (successor :: Int -> Maybe Int) (successor :: Int -> > Maybe Int) > -- print (show b1 ++ " " ++ show b2) > > main :: IO () > main = do > b2 <- eq f2 f2 > b1 <- eq f1 f1 > print (show b1 ++ " " ++ show b2) > where f1 = (successor :: Int -> Maybe Int) > f2 = (successor :: Int -> State Int Int) > > > > hth, > L. > > > > > On Tue, Jun 26, 2012 at 1:15 PM, Ismael Figueroa Palet < > ifigueroap(a)gmail.com> wrote: > >> I'm using StableNames to have a notion of function equality, and I'm >> running into problems when using monadic functions. >> >> Consider the code below, file Test.hs >> >> import System.Mem.StableName >> import Control.Monad.State >> >> eq :: a -> b -> IO Bool >> eq a b = do >> pa <- makeStableName a >> pb <- makeStableName b >> return (hashStableName pa == hashStableName pb) >> >> successor :: (Num a, Monad m) => a -> m a >> successor n = return (n+1) >> >> main :: IO () >> main = do >> b1 <- eq (successor :: Int -> Maybe Int) (successor :: Int -> >> Maybe Int) >> b2 <- eq (successor :: Int -> State Int Int) (successor :: Int -> >> State Int Int) >> print (show b1 ++ " " ++ show b2) >> >> Running the code into ghci the result is "False False". There is some old >> post saying that this is due to the dictionary-passing style for >> typeclasses, and compiling with optimizations improves the situation. >> >> Compiling with ghc --make -O Tests.hs and running the program, the result >> is "True True", which is what I expect. >> However, if I change main to be like the following: >> >> main :: IO () >> main = do >> b2 <- eq (successor :: Int -> State Int Int) (successor :: Int -> >> State Int Int) >> b1 <- eq (successor :: Int -> Maybe Int) (successor :: Int -> >> Maybe Int) >> print (show b1 ++ " " ++ show b2) >> >> i.e. just changing the sequential order, and then compiling again with >> the same command, I get "True False", which is very confusing for me. >> Similar situations happens when using the state monad transformer, and >> manually built variations of it. >> >> It sounds the problem is with hidden closures created somewhere that do >> not point to the same memory locations, so StableNames yields false for >> that cases, but it is not clear to me under what circumstances this >> situation happens. Is there other way to get some approximation of function >> equality? or a way to "configure" the behavior of StableNames in presence >> of class constraints? >> >> I'm using the latests Haskell Platform on OS X Lion, btw. >> >> Thanks >> >> -- >> Ismael >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -- Ismael

2 7

HXT: Replace an element with its text
by Michael Orlitzky 26 Jun '12

26 Jun '12

I would like to replace, <body><a href="#">foo</a></body> with, <body>foo</body> using HXT. So far, the closest I've come is to parse the HTML and apply the following stuff: is_link :: (ArrowXml a) => a XmlTree XmlTree is_link = hasName "a" replace_links_with_their_text :: (ArrowXml a) => a XmlTree XmlTree replace_links_with_their_text = processTopDown $ (getText >>> mkText) `when` is_link Unfortunately, this just removes the "a" element and its text entirely. The other-closest solution is, replace_links_with_their_text :: (ArrowXml a) => a XmlTree XmlTree replace_links_with_their_text = processTopDown $ (txt "foo") `when` is_link Of course, I don't want to hard-code the value "foo", and I can't figure out a way to feed the element's text back into 'txt'. Anyone tried this before?

3 5

StableNames and monadic functions
by Ismael Figueroa Palet 26 Jun '12

26 Jun '12

I'm using StableNames to have a notion of function equality, and I'm running into problems when using monadic functions. Consider the code below, file Test.hs import System.Mem.StableName import Control.Monad.State eq :: a -> b -> IO Bool eq a b = do pa <- makeStableName a pb <- makeStableName b return (hashStableName pa == hashStableName pb) successor :: (Num a, Monad m) => a -> m a successor n = return (n+1) main :: IO () main = do b1 <- eq (successor :: Int -> Maybe Int) (successor :: Int -> Maybe Int) b2 <- eq (successor :: Int -> State Int Int) (successor :: Int -> State Int Int) print (show b1 ++ " " ++ show b2) Running the code into ghci the result is "False False". There is some old post saying that this is due to the dictionary-passing style for typeclasses, and compiling with optimizations improves the situation. Compiling with ghc --make -O Tests.hs and running the program, the result is "True True", which is what I expect. However, if I change main to be like the following: main :: IO () main = do b2 <- eq (successor :: Int -> State Int Int) (successor :: Int -> State Int Int) b1 <- eq (successor :: Int -> Maybe Int) (successor :: Int -> Maybe Int) print (show b1 ++ " " ++ show b2) i.e. just changing the sequential order, and then compiling again with the same command, I get "True False", which is very confusing for me. Similar situations happens when using the state monad transformer, and manually built variations of it. It sounds the problem is with hidden closures created somewhere that do not point to the same memory locations, so StableNames yields false for that cases, but it is not clear to me under what circumstances this situation happens. Is there other way to get some approximation of function equality? or a way to "configure" the behavior of StableNames in presence of class constraints? I'm using the latests Haskell Platform on OS X Lion, btw. Thanks -- Ismael

1 0

Hackage 2 maintainership
by Ben Gamari 26 Jun '12

26 Jun '12

Hey all, Those of you who follow the Haskell subreddit no doubt saw today's post regarding the status of Hackage 2. As has been said many times in the past, the primary blocker at this point to the adoption of Hackage 2 appears to be the lack of an administrator. It seems to me this is a poor reason for this effort to be held up. Having taken a bit of time to consider, I would be willing to put in some effort to get things moving and would be willing to maintain the haskell.org Hackage 2.0 instance going forward if necessary. I currently have a running installation on my personal machine and things seem to be working as they should. On the whole, installation was quite trivial, so it seems likely that the project is indeed at a point where it can take real use (although a "logout" option in the web interface would make testing a bit easier). That being said, it would in my opinion be silly to proceed without fixing the Hackage trac. It was taken down earlier this year due to spamming[1] and it seems the recovery project has been orphaned. I would be willing to help with this effort, but it seems like the someone more familiar with the haskel.org infrastructure might be better equipped to handle the situation. It seems that this process will go something like this, 1) Bring Hackage trac back from the dead 2) Bring up a Hackage 2 instance along-side the existing hackage.haskell.org 3) Enlist testers 4) Let things simmer for a few weeks/months ensuring nothing explodes 5) After it's agreed that things are stable, eventually swap the Hackage 1 and 2 instances This will surely be a non-trivial process but I would be willing to move things forward. Cheers, - Ben [1] http://www.haskell.org/pipermail/cabal-devel/2012-January/008427.html

12 17

Munich Haskell Meeting
by Heinrich Hördegen 25 Jun '12

25 Jun '12

Dear all, once again, we want to invite you to our monthly Munich Haskell Meeting at Thu, 28th of June, at 19h30. This time, the venue will be Max Emanuell Brauerei in Munich (http://www.max-emanuel-brauerei.de/) Be aware of that change! Thursday will also be the day of a local football play, at least for those living in Europe. Therefore, I want to reserve a table on Wednesday in order to get a table at all. If you plan to join, please go to: http://www.haskell-munich.de/dates and click the button. Until then, have fun. Heinrich

1 0

Galois is hiring!
by Jason Dagit 25 Jun '12

25 Jun '12

We're looking for functional programmers, formal methods practitioners, and project leads, interested in either short term or permanent employment. For more information, see: http://corp.galois.com/careers Why Galois? At Galois, we believe in seeking out and solving important problems to make the world a better place. This philosophy runs through everything we do. From internal interactions on an individual level to the interesting technical challenges we take on to the way we orient to the external world. We hire the best people, we help them to better understand their own passions, and then together we take on important problems. It just so happens that we have skilled software engineers with a passion for functional programming who take on challenges in crypto, critical systems, secure networking, and so on. For me, the very compelling reasons to work at Galois are: a strong cultural emphasis on freedom to choose your roles within the organization including seeking external funding to work on whatever you want; strong commitment to open source, and; a cultural emphasis on functional programming and formal methods. What a organization believes has a deep and profound impact on how you spend your time at the organization, who the organization attracts, and what impact the organization will have in the world. We have no shortage of interesting problems to tackle in our quest to make the world a better place. Thanks, Jason

1 0

ghci session slows down over time.
by Jonathan Geddes 25 Jun '12

25 Jun '12

Haskell Cafe, I'm seeing crazy amounts of slowdown in a ghci session after just a few executions of :r (reload). Using :set +r (revert top-level bindings) doesn't seem to help. Is it possible that the dynamically-loaded object code is not being garbage collected? Is this a known issue? More importantly, is there a known workaround? Thanks, --J Arthur

3 3

Origin of Delimited Continuation Operators
by aditya siram 25 Jun '12

25 Jun '12

Hi all, I working through a few papers and Oleg's delimited continuation implementation and I'm wondering how the operators (shift, shift0P, control, reset, etc) got their name. -deech

2 2

About using "type" to do type alias.
by Magicloud Magiclouds 25 Jun '12

25 Jun '12

Hi, There was another mail, but the subject might be confusing. So I write this one. The code is here: http://hpaste.org/70414 If I understand correct, generally, I could use 'type' to do alias to save the ugly-long code. Like section 1. This works when I 't [(0, Just "x")]'. But, if I wrote section 2. Then 'start (M.fromList $ zip ord_args) worker' could not be compiled due to the second argument is type of 'M.Map Arg Arg', not 'JobArgs Arg Arg'. What did I miss to make this work? -- 竹密岂妨流水过山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.

3 9

ICFP Student Research Competition
by Wouter Swierstra 25 Jun '12

25 Jun '12

===================================================================== Student Research Competition Associated with the The 17th ACM SIGPLAN International Conference on Functional Programming (ICFP 2012) and affiliated events http://www.icfpconference.org/icfp2012/src.html Copenhagen, Denmark, Sep 9-15, 2012 ===================================================================== This year ICFP will host a Student Research Competition where undergraduate and postgraduate students can present posters. The SRC at the ICFP 2012 consists of three rounds: - Extended abstract round: All students are encouraged to submit an extended abstract outlining their research (800 words). - Poster session at ICFP 2012: Based on the abstracts, a panel of judges will select the most promising entrants to participate in the poster session which will take place at ICFP. Students who make it to this round will be supported to attend the conference, to a maximum of $500 for travel and housing. If your total costs are higher than these $500 your conference fee may be waived too. In the poster session, students will have the opportunity to present their work to the judges, who will select three finalists in each category* (graduate/undergraduate) to advance to the next round. - ICFP presentation: The next round consists of an oral presentation at the ICFP to compete for the final awards in each category. ** Prizes ** Both the top three graduate and the top three undergraduate contestants will receive prizes of $500, $300, and $200, respectively. All six winners will receive award medals and a two-year complimentary ACM student membership, including a subscription to ACM’s Digital Library. The names of the winners will be posted on the SRC web site. The winners in each category will be invited to participate in the ACM SRC Grand Finals, an on-line round of competitions among the winners of other conference-hosted SRCs. Grand Finalists and their advisors will be invited to the Annual ACM Awards Banquet for an all-expenses-paid trip, where they will be recognized for their accomplishments along with other prestigious ACM award winners, including the winner of the Turing Award (also known as the Nobel Prize of Computing). The top three graduate Grand Finalists will receive an additional $500, $300, and $200. Likewise, the top three undergraduate Grand Finalists will receive an additional $500, $300, and $200. All six Grand Finalists will receive Grand Finalist certificates. ** Eligibility ** The SRC is open to both undergraduate and graduate students. Upon submission, entrants must be enrolled as a student at their university. The abstract must describe the student’s individual research and must be authored solely by the student. If the work is collaborative with others and/or part of a larger group project, the abstract should make clear what the student’s role was and should focus on that portion of the work. The extended abstract must not exceed 800 words and must not be longer than 2 pages. The reference list does not count towards these limits. To submit an abstract, please register through the submission page and follow the instructions. Abstracts submitted after the deadline may be considered at the committee's discretion, but only after decisions have been made on all abstracts submitted before the deadline. If you have any problems, don't hesitate to contact the competition chair. More information about the submission process can be found online at: http://www.icfpconference.org/icfp2012/src.html ** Important Dates ** Deadline for submission: June 29th Notification of acceptance: July 8th ** Selection Committee ** Koen Claessen, Chalmers University of Technology Robby Findler (ICFP Program chair), Northwestern University Ken Friis Larsen, IT University of Copenhangen Jacques Garrigue, Nagoya University Doaitse Swierstra (Chair), Utrecht University

1 0