January 2017 - Haskell-Cafe

[ANN] FloatingHex: Hexadecimal floats (quasiquoter and pretty-printer)
by Levent Erkok 17 Jan '17

17 Jan '17

FloatingHex (http://hackage.haskell.org/package/FloatingHex) is a simple package that implement hexadecimal notation for floating point numbers, as described in p57-58 of http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf The package provides a quasi-quoter for hexadecimal floats: hf, and a pretty-printer for floats to show them in this notation: showFFloat. (Note that the latter is not 100% compatible with C's %a modifier for printf, but it does render a faithful representation of its input.) Hex-floats are useful as they allow writing floating-point constants without any loss of precision, while remaining human readable. For instance, the float 2 is written as 0x1p1. (With the quasiquoter, the syntax is [hf|0x1p1|].) This representation is to be preferred over decimal rendering where loss of precision can be a problem: Note that not all floating point numbers have a terminating decimal representation as currently required by the Haskell syntax. It would be nice if Haskell itself allowed for such literals in the language specs itself, following the recent changes to other language standards. (Again, see p57-58 of http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf for the new C standard.) In the mean time, I hope FloatingHex library will provide a workaround for the numerophilias amongst us. Bug reports and improvements always welcome! Cheers, -Levent.

2 3

[ANN] Haskell ITA meetup in Milan, Italy (2017-02-25)
by Francesco Ariis 17 Jan '17

17 Jan '17

Good evening -cafe, the italian Haskell Community (http://haskell-ita.it/) is happy to announce its winter Haskell meetup. The event is going to be hosted in Milano, on February 25th (Saturday). It will be kindly hosted by MIKAMAI [1], Via Giulio e Corrado Venini, 42 - 20127 Milano (MI), IT [1] https://www.mikamai.com/ To register, check: https://www.metooo.io/e/incontro-haskell-ita-inverno-2017 Any haskeller (beginner, experienced, curious) is welcome! *** italian follows *** Buonasera a tutti, abbiamo finalmente deciso la data dell'incontro invernale di Haskell-ITA! Ci riuniremo il 25 Febbraio 2017 (un Sabato), presso MIKAMAI [1], che gentilmente mette i locali a disposizione. [1] https://www.mikamai.com/ L'indirizzo è: Via Giulio e Corrado Venini, 42 - 20127 Milano (MI), IT Per registrarvi: https://www.metooo.io/e/incontro-haskell-ita-inverno-2017

1 0

A question on datakinds syntax
by Haiwei Zhou 17 Jan '17

17 Jan '17

Hi, I am reading the document of spock-0.11, and found two strange definitions in the Web.Spock. ```` type Var a = Path ((:) * a ([] *)) Open var :: (Typeable * a, PathPiece a) => Path ((:) * a ([] *)) Open ```` What's the meaning of the star between Typeable and a ? The kind of Typeable is * -> *. I cannot understand why the Typeable in the var prototype takes two kinds. In the Web.Routing.Combinators of reroute-0.4, those are defined as following: ```` type Var a = Path (a ': '[]) Open var :: (Typeable a, PathPiece a) => Path (a ': '[]) Open ```` Why there are two difference definition about the same thing? Thanks, Haiwei

3 2

Control.Parallel seemingly randomly behaviour
by Juan Luis Martty 17 Jan '17

17 Jan '17

Hello everyone, I'm having a consistency issue with the following piece of code: heavyAm = 500 lightAm = 1000 heavyCalc :: Int -> Int heavyCalc s = sum [1..1000000*s] parallel = (heavyCalc lightAm, heavyCalc heavyAm) `using` (parTuple2 rseq rseq) For some reason, during runtime the RTS sometimes parallelizes the evaluation and sometimes it doesn't. I'm running with all the RTS/compile time options correctly afaik. Here is the output from a couple of runs of the program: jmartty@walrus:~/hs/parallel$ stack build && time stack exec par-exe Warning: File listed in par.cabal file does not exist: README.md (500000000500000000,125000000250000000) Computation time: 1.557007s real 0m1.732s user 0m2.528s sys 0m0.464s jmartty@walrus:~/hs/parallel$ stack build && time stack exec par-exe Warning: File listed in par.cabal file does not exist: README.md (500000000500000000,125000000250000000) Computation time: 1.544837s real 0m1.720s user 0m2.544s sys 0m0.712s jmartty@walrus:~/hs/parallel$ stack build && time stack exec par-exe Warning: File listed in par.cabal file does not exist: README.md (500000000500000000,125000000250000000) Computation time: 2.316537s real 0m2.484s user 0m2.592s sys 0m0.680s jmartty@walrus:~/hs/parallel$ stack build && time stack exec par-exe Warning: File listed in par.cabal file does not exist: README.md (500000000500000000,125000000250000000) Computation time: 2.318514s real 0m2.489s user 0m2.612s sys 0m0.688s jmartty@walrus:~/hs/parallel$ stack build && time stack exec par-exe Warning: File listed in par.cabal file does not exist: README.md (500000000500000000,125000000250000000) Computation time: 1.544975s real 0m1.718s user 0m2.512s sys 0m0.456s As you can see, sometimes wall time roughly equals userspace time, sometimes it doesn't (meaning it parallelized at least some amount). I'm running on a dual core machine under Ubuntu using stack with lts-7.14 (GHC 8.0.1) and parallel-3.2.1.0. Regards, Juan

2 3

Re: [Haskell-cafe] Hyper-recursion?
by Anthony Clayden 17 Jan '17

17 Jan '17

>> On 16 Jan 2017 04:43, "Lawrence Bottorff" <borgauf at gmail.com> wrote: >> >> A while back I worked at an assessor's office, i.e., the people responsible >> for handling properties as land parcels. ... Hi Lawrence, I too worked on land parcels -- a local government rates billing and land valuation application. >> ... how property changed hands, and especially how property lines >> changed due to properties either merging or being split up. >> That is to say, how the parcel map changed over time. I think the important aspect is that the a parcel can be split, and one of the splits merged with another parcel that was not originally with it. (I don't know how it was in your application. but in mine a legal parcel might consist of discontiguous areas of land -- for example a house in a terrace parcelled with a garage amongst a block of garages at the end of the street,) That is, looking over history you cannot group the parcels into a strict hierarchy of splits. >> Somewhere in the functional paradigm, specifically recursion, >> would seem to be a model for this issue. No I'm not seeing anything specifically functional about this. It's a directed graph, where each node is an instance of parcel ownership. >> So in chapter 1 of any functional programming tutorial is the factorial >> calculation function done with recursion. We beginners see the recursion >> "going out" to the "last one," then "coming back," adding up the results of >> each stage as it returns . . . like a yo-yo winding out, >> then winding up again. Nice image, but there's no "last one" here (nor a "first one" that we could make sense of), There's no boundary from where we could be "coming back". Recursion does not apply [see more below] >> David Turner dct25-561bs at mythic-beasts.com >> Mon Jan 16 07:47:41 UTC 2017 >> >> I suspect you have stumbled onto the dual concept of corecursion: ... Nor corecursion. a) because of the infinite and arbitrary potential for splits/mergers; b) because even if there was some time in the distant past when the whole country was a single parcel with a single owner. (The Emperor? But even empires and countries split and merge. Or no owner, only hunter-gatherers/nomads, which might as well be a single parcel.) We're never going to try to rebuild that history. c) because there's never going to be a future end-state. Arbitrary splits/mergers will continue forever. We can't predict what might be the smallest parcels some area of land could be split into. (Note that one trick to prevent mineral exploitation companies from buying up glorious scenery is to split it into $1-parcels and sell each to a different owner.) >> ... Haskell being the most pure functional language, is, hence, >> my starting point on this question. There's nothing specifically Haskell in this. A better place to ask might be lambda-the-ultimate. Anthony

4 3

dynamic code compilation and loading
by Dennis Raddle 17 Jan '17

17 Jan '17

Hello, I wrote a Haskell program which reads a MusicXML score and plays it through real-time MIDI messages (using the portmidi module) via some algorithms that are customized depending on the MIDI synthesizer that is receiving the messages. The program also plays back the music with musically expressive nuances. In the next version of this program, I am going to add more complicated algorithms for the expressive nuances, and it would be helpful to configure them and express them in actual Haskell code. My workflow will look like this: A. write a score using the music typesetting program Sibelius B. write some Haskell code to provide expressive nuances C. play the music through a MIDI synthesizer and listen. D. based on what I hear and where I want to take the music, modify the score and the Haskell code E. loop back to C Therefore, if I don't want to recompile the program each time I do step D, I need to compile and load code dynamically. Let's say that a data structure which contains a MusicXML score and a nominal rendition into MIDI messages together with time tags is of type Score. Then I want to write, and dynamically compile/load, a function vary :: Score -> Score which varies the MIDI messages and time tags to add expressive nuances. Let's say 'vary' is contained in Vary.hs. I want to write 'vary' in terms of already-compiled functions that provide the basic music-processing operations. Let's say that these functions are in the module MusicBase. Then Vary.hs will look like import MusicBase vary = ... operations in MusicBase ... Can I get some basic idea of how to do this? D

3 5

Hyper-recursion?
by Lawrence Bottorff 16 Jan '17

16 Jan '17

A while back I worked at an assessor's office, i.e., the people responsible for handling properties as land parcels. I was brought in to do GIS. One of the things we wanted was to get a sense of the history of land use, specifically how property changed hands, and especially how property lines changed due to properties either merging or being split up. That is to say, how the parcel map changed over time. Problematic was how the rugged old mainframe system (IBM AS/400 and a Cobol app) simply updated the data -- with no concept of remembering how things used to be. My GIS system (ESRI) also lacked any state memory -- other than simply snapshooting everything ad nauseum. Years later I become familiar with the world of functional programming. Somewhere in the functional paradigm, specifically recursion, would seem to be a model for this issue. That is, the whole issue of parcels changing through merges or splits might be a simple question of recursion. If functional is "beyond state," then changes in a map would only be stages, places in a never-ending outward-growing recursion. Seen as "infinite mirrors," one map change would simply be a mirror layer -- click on it to call it up. So in chapter 1 of any functional programming tutorial is the factorial calculation function done with recursion. We beginners see the recursion "going out" to the "last one," then "coming back," adding up the results of each stage as it returns . . . like a yo-yo winding out, then winding up again. But what I'm describing with changing parcels maps would seem to be a process that never comes out of recursion, rather, lives inside a "hyper-recursion." That is to say, an overarching recursion is the whole world. However, today's mentality would simply say, *Obviously, you want to save off each change you make to your parcel map *. . . again, the whole snapshot idea. This thinking is typical data management coupled, perhaps, with the human penchant to see things in terms of time and timelines. So, again, the standard solution would be to timestamp a parcel change and save it off, i.e., a "change" is a tick on the timeline, mark it, make note of it. But again, couldn't we see this whole issue of parcel changes as (using my yo-you analogy) just levels in what seems like a continual winding out -- which in a topological sense doesn't even need to be seen as geographical? This would seem to put the *process in a recursion,* rather than *recursion(s) in a process.* Haskell being the most pure functional language, is, hence, my starting point on this question. I'm a bright enough person, but I can't believe I'm the first person to notice this Alice in Wonderland situation. . . BTW, we could see a chess game in a similar light. . . . if not many, many other evolving phenomena of supposed (cumulative, consequential?) change. Thanks, Lawrence Bottorff

3 2

BayHac 2017 announcement
by Dan Burton 15 Jan '17

15 Jan '17

I am pleased to announce that BayHac 2017 will be held at the Takt office in San Francisco on the weekend of Friday, April 7th thru Sunday, April 9th. BayHac is a Haskell hackathon weekend event for the San Francisco Bay Area and Silicon Valley. It will be a weekend of learning, hacking, and connecting with fellow Haskell enthusiasts. See the page for BayHac 2017 on the haskell.org wiki for details: https://wiki.haskell.org/BayHac2017 -- Dan Burton

2 1

LambdaConf 2017 CFP
by John A. De Goes 15 Jan '17

15 Jan '17

The LambdaConf 2017 Call for Proposals <http://surveymonkey.com/r/lambdaconf-2017-cfp> (CFP) is open until the end of January: http://surveymonkey.com/r/lambdaconf-2017-cfp LambdaConf is an interdisciplinary functional programming conference held in the Mountain West, and seeks to bring together aspiring and practicing functional programmers, as well as researchers. Traditionally, the conference has had a very large amount of Haskell content (second only to Scala content in some years). The conference takes place May 25 - 27, in Boulder, Colorado, and is preceded by commercial training opportunities and a day of third-party mini-conferences on selected topics. If you are an educator, a researcher, a speaker, a speaker coach, or someone aspiring to one of the preceding, then we warmly welcome you to submit a proposal for LambdaConf 2017. All LambdaConf speakers receive free registration, an appreciation dinner, a special gift, accommodations for up to 4 nights (May 24 - May 28), and ample travel assistance based on need and availability. LambdaConf attracts everyone from the FP-curious to researchers; hobbyists and professionals; academics and commercial developers. Material at all levels, including beginner content and very advanced content, will find an audience at LambdaConf. LambdaConf welcomes the following kinds of proposals: Languages. Proposals that overview or dive into specific features of functional, math, or logic programming languages (both new and existing), with the goal of exposing developers to new ideas or helping them master features of languages they already know. Libraries. Proposals that discuss libraries that leverage functional or logic programming to help programmers solve real-world problems. Concepts. Proposals that discuss functional programming idioms, patterns, or abstractions; or concepts from mathematics, logic, and computer science, all directed at helping developers write software that's easier to test, easier to reason about, and easier to change safely. Aspects. Proposals that discuss how functional programming can help with specific aspects of modern software development, including scalability, distributed systems, concurrency, data processing, security, performance, correctness, user-interfaces, machine learning, and big data. Use Cases. Proposals that discuss how functional programming enabled a project or team to thrive, or deliver more business value than possible with other approaches. Cherry-Picking. Proposals that show how techniques and approaches from functional programming can be adapted and incorporated into mainstream development languages and practices, to the benefit of developers using them. Cracks. Proposals that call attention to difficulties of functional programming (both as a cautionary tale but also to raise awareness), especially such proposals that suggest alternatives or a path forward. Data. Proposals that present data, measurements, or analysis that suggests different techniques, paradigms, languages, libraries, concepts, or approaches have different efficacies for given specified metrics, which provide actionable takeaways to practicing functional and logic programmers. Off-Topic. Proposals that have appeal to a mainstream developer audience (the number of off-topic proposals we accept is small, but we do accept some, especially for keynotes). LambdaConf welcomes proposals for dynamic and static programming languages, category theoretic and otherwise, both functional and logic, or mainstream languages that can benefit from functional programming. Challengers and alternatives are also welcome. We are currently soliciting for the following session formats: Speaker Coaches. Speaker Coaches have extensive experience preparing material and giving polished, well-structured, educational, entertaining talks. Speaker Coaches review material and practice sessions for 5 - 10 speakers, & provide constructive feedback to speakers about how to improve the focus, content, & presentation of material. Coaches receive accommodations, free registration, & airfare reimbursement, & a 10 minute speaking slot (if interested). Leap Workshops. Leap Workshops take place on May 25, and are approximately 6 hours in length. They are in-depth, hands-on workshops designed to teach mainstream functional programming topics in enough detail, attendees can immediately apply what they learn in their jobs. Instructors for Leap Workshops receive accommodations, free registration, airfare reimbursement (including family), and a small stipend. If you are an author with a relevant book, we can also make it easy for attendees to purchase the book as part of registration for your workshop. Workshops must use a containerized cloud environment provided and paid for by LambdaConf. Hop Workshops. Hop Workshops are 2 hours in length. Like Leap Workshops, these workshops are in-depth and hands-on, but they cover reduced content and may be specialized to topics that may not have mainstream appeal. Guides receive accommodations, free registration, and travel assistance based on need and availability. Workshops must use a containerized cloud environment provided and paid for by LambdaConf. De Novo Sessions. De Novo Sessions are 1 hour in length. These sessions are designed to present original work from industry and academia. While the requirements for proposals are more rigorous, there is less competition for De Novo slots. Speakers receive accommodations, free registration, and travel assistance based on need and availability. Educational Sessions. Educational Sessions are 1 hour in length. These sessions are designed to clearly and concisely teach one useful concept, skill, aspect, library, or language to attendees. Teachers receive accommodations, free registration, and travel assistance based on need and availability. Inspire Talks. Inspire talks are 10 minutes in length and focus on clear communication of a single takeaway. These sessions are intended to inspire attendees to learn more about particular subjects or to try new approaches. Speakers receive accommodations, free registration, and travel assistance based on need and availability. Note: While only 10 minutes in length, we require a high-level of polish, structure, and rehearsal for Inspire Talks; despite shorter length, they are as much work to prepare for as other sessions. Keynotes. Keynotes are 40 minutes in length, and are presented before all attendees (there are no other sessions concurrent with keynotes). Keynotes are designed to offer thought-provoking, opinionated, and insightful commentary on topics of interest to the community. Keynotes have more latitude to stray from functional programming and into related areas such as computer science, mathematics, and science. Keynote speakers receive accommodations, free registration, and travel assistance based on need and availability. LambdaConf requires tailored content. This does not mean you cannot reuse existing content, only that you should incorporate updates into your material, respond to feedback from your speaker coach, and tailor the material to the LambdaConf audience as appropriate. Note: The Call for Proposals closes January 31. Submitters will be notified by March 1st at latest. -- John A. De Goes john(a)degoes.net Follow me on Twitter @jdegoes

1 0

The design and use of QuickCheck
by Joe Nelson 14 Jan '17

14 Jan '17

Hey Haskellers, I decided to learn more about QuickCheck because it seems useful, and after a two weeks of reading papers and trying experiments, I wrote about my findings. https://begriffs.com/posts/2017-01-14-design-use-quickcheck.html Hope you find the article useful. Cheers, Joe

1 0