December 2018 - Haskell-Cafe

Re: [Haskell-cafe] Faster set intersections?
by Olaf Klinke 11 Dec '18

11 Dec '18

> Note that a concrete set "concretizes" anything it touches. Don't take > unions of these sets, though, it'll just be a mess. > > > Won't a union just be the same as intersection but using || instead of && ? > > > -Jan-Willem Maessen Unions of predicates and concrete sets are easy, thanks to Set.member: union (Pred p) (Concrete s) = Pred (\k -> p k || member k s) What you can not do, of course, is enumerate and fold these sets. There is a set type [1] which supports a litte bit more: Set a = Maybe ((a -> Bool) -> a) It has unions, intersections and a Monad instance and can represent infinite sets. If the base type has an Ord instance, the set can be enumerated. If the base type has an Eq instance, so has (Set a). Some functions usually implemented using Foldable are also possible, e.g. minimum and maximum. Caveat: Performance can be poor, depending on how the function inside the set was defined. Cheers, Olaf [1] http://hackage.haskell.org/package/infinite-search

7 11

Is unfoldr too strict?
by Isaac Elliott 11 Dec '18

11 Dec '18

I was reading this article https://wiki.haskell.org/Correctness_of_short_cut_fusion on the Haskell wiki. It presents an example (2.1.2) where destroy/unfoldr fusion behaves oddly. If I use a lazier definition of unfoldr, then this problem goes away: unfoldr :: (b -> Maybe (a, b)) -> b -> [a] > unfoldr f b = > case f b of > Nothing -> [] > Just z -> fst z : unfoldr f (snd z) Does this mean unfoldr is 'too strict'? Or is there a good reason for not writing it this way (performance, perhaps?)

2 2

References for topological arguments of programs?
by Siddharth Bhat 11 Dec '18

11 Dec '18

Hello, I was recently intrigued by this style of argument on haskell cafe: One can write a function Eq a => ((a -> Bool) -> a) -> [a] that enumerates the elements of the set. Because we have universal quantification, this list can not be infinite. Which makes sense, topologically: These so-called searchable sets are topologically compact, and the Eq constraint means the space is discrete. Compact subsets of a discrete space are finite. ------- I've seen arguments like these "in the wild" during Scott topology construction and in some other weird places (hyperfunctions), but I've never seen a systematic treatment of this. I'd love to have a reference (papers / textbook preferred) to self learn this stuff! Thanks Siddharth -- Sending this from my phone, please excuse any typos!

10 12

version sorting?
by Javran Cheng 11 Dec '18

11 Dec '18

Hi Cafe, I'm wondering if there's any existing packages that do "version sorting": as an example, for a list like: ["foo-10.20", "foo-1.2", "foo-2.100", "foo-1.12"] I'd like the result to be: ["foo-1.2", "foo-1.12", "foo-2.100", "foo-10.20"] I could think of an implementation that turns String elements of a list into [Either Int String] by grouping consecutive chunks using span and isDigit and then do a sortOn: versionSort :: [String] -> [String] versionSort = sortOn brkND where tr f g (x,y) = f x : g y -- ND for non-digits brkND = tr Right brkD . span (not . isDigit) brkD = tr (Left . read @Int) brkND . span isDigit (side question: does the helper function tr I defined above have a commonly known name?) just wondering if there are more sophisticated solutions available. Best, Javran

6 9

Re: [Haskell-cafe] Literate Haskell to HTML?
by David Banas 10 Dec '18

10 Dec '18

Hi Olaf, Yes, I routinely generate HTML from *.lhs files, using Pandoc. -db > On Dec 10, 2018, at 3:03 PM, haskell-cafe-request(a)haskell.org wrote: > > Does anyone know whether literate haskell can be used to generate html?

1 0

Coercion Quantification-related Meetup Event in Hong Kong (December 13, 2018)
by Tomas Tauber 10 Dec '18

10 Dec '18

FYI: https://www.meetup.com/HK-Functional-programming/events/256404067/ <https://www.meetup.com/HK-Functional-programming/events/256404067/>

1 0

Re: [Haskell-cafe] Faster set intersections?
by Doug McIlroy 10 Dec '18

10 Dec '18

> The following expressions both cause GHCI to hang: > > S.intersection (S.fromList [1,2]) (S.fromList [1..]) > S.intersection (S.fromList [1..]) (S.fromList [1,2]) > > Is there a smarter way to take the intersection of sets when at least one > of them is small (but I don't know which one that is)? "Small" is not enough. If all you know is that the lists represent sets of integers, then S.intersection (S.fromList [-1,-2]) (S.fromList [1..]) must diverge. A sufficient condition for success in such examples is that the sets come from a well-ordered domain and are presented in order. Then it's easy to write a merge-like algorithm. Both sets can be infinite; every finite prefix of the intersection will eventually appear. (Note that the integers are not well-ordered, though the positive integers are.) Doug

2 1

Faster set intersections?
by Jeffrey Brown 09 Dec '18

09 Dec '18

The following expressions both cause GHCI to hang: > S.intersection (S.fromList [1,2]) (S.fromList [1..]) fromList ^CInterrupted. > S.intersection (S.fromList [1..]) (S.fromList [1,2]) fromList ^CInterrupted. > Is there a smarter way to take the intersection of sets when at least one of them is small (but I don't know which one that is)? -- Jeff Brown | Jeffrey Benjamin Brown Website <https://msu.edu/~brown202/> | Facebook <https://www.facebook.com/mejeff.younotjeff> | LinkedIn <https://www.linkedin.com/in/jeffreybenjaminbrown>(spammy, so I often miss messages here) | Github <https://github.com/jeffreybenjaminbrown>

6 5

Stack data structure
by daniel huebleitner 08 Dec '18

08 Dec '18

I am a graduate student in theoretical computer science playing around with haskell for the past year or so. I wrote a Stack Data structure today and would like to get some feedback from more experienced haskellers if possible. I know its a really simple thing to write. But the implementation I found on hackage wasn't what I was looking for. I haven't wrote unit tests yet, but it should behave as expected. Thanks in advance. Kind regards. Daniel

5 5

Re: [Haskell-cafe] [Haskell] Guidelines for respectful communication
by Dan Burton 07 Dec '18

07 Dec '18

Thank you, Simon. My experience with the Haskell community has been quite positive over the years. I am continually pleased to see community leaders make an intentional effort to maintain the Haskell community's reputation of kindness, helpfulness, and inclusiveness. Say what you will about design-by-committee processes, but the growing Haskell community -- with the increasing diversity that comes with that -- is refining, extending, and supporting the language in new and interesting ways. By intentionally and explicitly embracing these patterns of respectful communication, you facilitate the continued growth and improvement of the language. Thank you again for the careful thought you have put into the topic of communication. Your effort is greatly appreciated! -- Dan Burton On Thu, Dec 6, 2018 at 5:35 AM Simon Peyton Jones via Haskell < haskell(a)haskell.org> wrote: > Friends > As many of you will know, I have been concerned for several years about > the standards of discourse in the Haskell community. I think things have > improved since the period that drove me to write my Respect email< > https://mail.haskell.org/pipermail/haskell/2016-September/024995.html>, > but it's far from secure. > We discussed this at a meeting of the GHC Steering Committee< > https://github.com/ghc-proposals/ghc-proposals> at ICFP in September, and > many of us have had related discussions since. Arising out of that > conversation, the GHC Steering Committee has decided to adopt these > Guidelines for respectful communication< > https://github.com/ghc-proposals/ghc-proposals/blob/master/GRC.rst> > > We are not trying to impose these guidelines on members of the Haskell > community generally. Rather, we are adopting them for ourselves, as a > signal that we seek high standards of discourse in the Haskell community, > and are willing to publicly hold ourselves to that standard, in the hope > that others may choose to follow suit. > We are calling them "guidelines for respectful communication" rather than > a "code of conduct", because we want to encourage good communication, > rather than focus on bad behaviour. Richard Stallman's recent post< > https://lwn.net/Articles/769167/> about the new GNU Kind Communication > Guidelines<https://gnu.org/philosophy/kind-communication.html> expresses > the same idea. > Meanwhile, the Stack community is taking a similar approach< > https://www.snoyman.com/blog/2018/11/proposal-stack-coc>. > Our guidelines are not set in stone; you can comment here< > https://github.com/ghc-proposals/ghc-proposals/commit/373044b5a78519071b9a2…>. > Perhaps they can evolve so that other Haskell committees (or even > individuals) feel able to adopt them. > The Haskell community is such a rich collection of intelligent, > passionate, and committed people. Thank you -- I love you all! > Simon > > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell >

2 1