- Haskell-Cafe - Haskell.org

compiling GHC 7.8 on raspberry pi
by Sven Bartscher 23 Apr '15

23 Apr '15

Greetings, I'm trying to get a haskell program to run on a raspberry pi (running raspbian). Unfortunately it requires template haskell. Since the GHC included in raspbian wheezy doesn't support TH I'm trying to compile GHC 7.8.4 on the rpi. Most of the compilation worked fine. I got problems with the memory consumption, but adding a lot of swapspace solved this problem. During the final phase the compilation process complains about a "strange closure type 49200" (the exact number is varying, but most often it's 49200). Does anyone here have experience, how to compile GHC 7.8 on a raspberry pi? As a side note: The compilation is running in QEMU while the compiled program should run on a real rpi. Regards Sven

3 3

[FUN] Cheryl's birthday; solved using Haskell/SBV
by Levent Erkok 23 Apr '15

23 Apr '15

For those of us who'd rather have Haskell do the thinking for us: https://gist.github.com/LeventErkok/654a86a3ec7d3799b624 Honestly, this is more an exercise in how to formalize such puzzles as opposed to demonstrating the capabilities of SBV or SMT-solvers in general; but fun nonetheless. The backend SMT solver (I used Z3) solves the puzzle instantly. Enjoy.. -Levent. PS. Thanks to Amit Goel for suggesting the formalization strategy used in the encoding.

1 0

cabal install glade
by Jean Lopes 22 Apr '15

22 Apr '15

Hello, I am trying to install the Glade package from hackage, and I keep getting exit failure... Hope someone can help me solve it! What I did: $ mkdir ~/haskell/project $ cd ~/haskell/project $ cabal sandbox init $ cabal update $ cabal install alex $ cabal install happy $ cabal install gtk2hs-buildtools $ cabal install gtk #successful until here $ cabal install glade The last statement gave me the following error: $ [1 of 2] Compiling SetupWrapper ( /tmp/cairo-0.12.5.3-5133/cairo-0.12.5.3/SetupWrapper.hs, /tmp/cairo-0.12.5.3-5133/cairo-0.12.5.3/dist/dist-sandbox-acbd4b7/setup/SetupWrapper.o ) $ $ /tmp/cairo-0.12.5.3-5133/cairo-0.12.5.3/SetupWrapper.hs:91:17: $ Ambiguous occurrence ‘die’ $ It could refer to either ‘Distribution.Simple.Utils.die’, $ imported from ‘Distribution.Simple.Utils’ at /tmp/cairo-0.12.5.3-5133/cairo-0.12.5.3/SetupWrapper.hs:8:1-32 $ or ‘System.Exit.die’, $ imported from ‘System.Exit’ at /tmp/cairo-0.12.5.3-5133/cairo-0.12.5.3/SetupWrapper.hs:21:1-18 $ Failed to install cairo-0.12.5.3 $ [1 of 2] Compiling SetupWrapper ( /tmp/glib-0.12.5.4-5133/glib-0.12.5.4/SetupWrapper.hs, /tmp/glib-0.12.5.4-5133/glib-0.12.5.4/dist/dist-sandbox-acbd4b7/setup/SetupWrapper.o ) $ $ /tmp/glib-0.12.5.4-5133/glib-0.12.5.4/SetupWrapper.hs:91:17: $ Ambiguous occurrence ‘die’ $ It could refer to either ‘Distribution.Simple.Utils.die’, $ imported from ‘Distribution.Simple.Utils’ at /tmp/glib-0.12.5.4-5133/glib-0.12.5.4/SetupWrapper.hs:8:1-32 $ or ‘System.Exit.die’, $ imported from ‘System.Exit’ at /tmp/glib-0.12.5.4-5133/glib-0.12.5.4/SetupWrapper.hs:21:1-18 $ Failed to install glib-0.12.5.4 $ cabal: Error: some packages failed to install: $ cairo-0.12.5.3 failed during the configure step. The exception was: $ ExitFailure 1 $ gio-0.12.5.3 depends on glib-0.12.5.4 which failed to install. $ glade-0.12.5.0 depends on glib-0.12.5.4 which failed to install. $ glib-0.12.5.4 failed during the configure step. The exception was: $ ExitFailure 1 $ gtk-0.12.5.7 depends on glib-0.12.5.4 which failed to install. $ pango-0.12.5.3 depends on glib-0.12.5.4 which failed to install. Important: You can assume I don't know much. I'm rather new to Haskell/cabal

4 9

Help wanted with Wiki.Haskell.Org
by Gershom B 21 Apr '15

21 Apr '15

One of the central repositories of knowledge in the Haskell world is the HaskellWiki (https://wiki.haskell.org) This wiki has been with the Haskell community for years, and contains a wealth of knowledge. Like other services on the haskell.org domain and with haskell.org equipment, ultimate responsibility for maintaining it falls on the Haskell Committee. However, it is a community wiki, and requires care and maintenance and contributions from all of us. The wiki has been, and continues to be, a vital component in the Haskell world. Like any wiki, it is fueled by contributions from many people, and in this sense it is thriving. However, it could use a certain amount of attention and work in three key areas. We are looking for volunteers to step up in these regards, 1) Account Creation Management: Account creation is manual only because spambots otherwise destroy us. It would be worth investigating if a full upgrade and new plugins could help this issue. In the meantime, the responsibility for creating new accounts has fallen on only one person for years. This is not a good situation. We would like to set up a mail alias for wiki admins and extend account creation rights to a range of people. If you would be willing to be one of a team of responders to account creation requests, please write and let us know. 2) Technical and design oversight: Now that we have a new haskell.org homepage, the current wiki frontpage could use a redesign. For that matter, the whole wiki could use a bit of a redesign to bring it into a more modern style. Along with that, it may be the case that additional plugins — such as for typesetting code or equations better — could be quite helpful. It would be good to have a mediawiki admin who wants to help improve the technical capacities of the site, as well as to overhaul its look. Again, if you are interested in taking charge of this, please let us know. 3) Content curation: One issue with a large collection of documents written by different people is the lack of curation. Some pages fall out of date, information is spread across multiple pages instead of collected together, and quality varies greatly. Without a central authority, no one is responsible (or empowered) to fix the situation. There is a balance between keeping things up-to-date and preserving the historic content of the wiki, and without people feeling empowered to make big changes, the tendency will always fall towards the latter. We're looking for people in the community to volunteer to help improve this status quo. The task, generally speaking, is to be responsible for curating and improving the content of the wiki, but that's clearly a vague description with lots of room for individual embellishment. This doesn't need to be a single person either: a team working in a coordinated fashion could be incredibly effective. Once more, depending on response, we’d be happy to designate and empower people to make broader changes on the wiki or to organize a team to do so. If you are interested in this as well, please let us know. Gershom, for the Haskell.org Committee

6 7

haskell.org
by Ertugrul Söylemez 21 Apr '15

21 Apr '15

Hi everybody, I'd like to note that the prime "sieve" example that is sitting at the top of the homepage is not a real sieve and will more likely make people with number theory experience (like me) feel highly irritated rather than fascinated. A real sieve does not only run a million times (!) faster and consumes far less memory, but is also much longer, even in Haskell. Here is a real one: <http://lpaste.net/101980> I don't want to make a mountain out of a molehill, but please note: If I'd be new to Haskell, that example would have turned me off, because it would have hurt my ability to take Haskell programmers seriously. You can easily promote your tools when you claim that they can build a car easily, except in reality it's just a toy bicycle. It's the same feeling to cryptographers when people call a regular stream cipher a "one-time pad" and promote it as such. It rings the "this is snake oil!" alarm bell. So I propose to either rename the 'sieve' function to something more appropriate (like `trialDiv`) or replace the example altogether. I would suggest an example that truly shows Haskell's strengths. Trial division search is really just a bad substitute for the more common and equally inappropriate list quicksort example. Greets, Ertugrul

9 14

Looking for Senior Software Engineers
by Jonathan Fischoff 21 Apr '15

21 Apr '15

Dear Haskellers, There are two senior software engineer openings at skedge.me, a Haskell and NixOS based company located in Manhattan NY. Here are the job postings. http://www.indeed.com/cmp/skedge.me/jobs/Senior-Software-Engineer-18d7f042d… http://www.indeed.com/cmp/skedge.me/jobs/Senior-Software-Engineer-b62e69029… Professional Haskell experience is not required. Provided you have experience maintaining and developing web services, this is your chance to become a professional Haskeller (if you're not one already). Relocation will be provided, but remote is not an option. Please send your resumes to jobs(a)skedge.me if you are interested. Sincerely, Jonathan Fischoff VP of Engineering at skege.me

1 0

ANN: Upload agentx, Library for write extensible SNMP agents.
by Алексей Смирнов 21 Apr '15

21 Apr '15

Can be useful for create monitoring tools. Usage example in docs. get, set, walk, context is work. Bulk work as simple get. Tables don't work, Indexes don't work. https://hackage.haskell.org/package/agentx https://github.com/chemist/agentx -- Alexey Smirnov.

1 0

[ANN] Haskell Music - Two tracks in the Jungle style
by Anton Kholomiov 21 Apr '15

21 Apr '15

Dear list. I'd like to share two new tracks made in haskell (with csound-expression lib). They are two etudes in the style of the Jungle. One track is just a joke. I hope that Simon doesn't mind me sampling him. The track is made in Haskell :) So it's a musical thank-you for the wonderful language! https://soundcloud.com/anton-kho/jungle-etude-1 https://soundcloud.com/anton-kho/jungle-etude-2-feat-simon-peyton-jones Anton

2 2

ANN: ssh, darcsden vulnerability
by Simon Michael 20 Apr '15

20 Apr '15

We recently learned of a serious undocumented vulnerability in the ssh <http://hackage.haskell.org/package/ssh> package. This is a minimal ssh server implementation used by darcsden <http://hackage.haskell.org/package/darcsden> to support darcs push/pull. If you use the ssh package, or you have darcsden’s darcsden-ssh server running, you should upgrade to/rebuild with the imminent ssh-0.3 release right away. Or if you know of someone like that, please let them know. Also, if you're interested in cryptography/security, additional help and patches for the ssh and darcsden packages would be very welcome. I've blogged more details at http://joyful.com/blog/2015-04-20-ssh-darcs-hub-vulnerability.html <http://joyful.com/blog/2015-04-20-ssh-darcs-hub-vulnerability.html> (if you're a Darcs Hub user, hopefully you've already seen it). Best - Simon

1 0

Attempt to emulate subclasses in Haskell, am I reinventing the wheel?
by Clinton Mead 20 Apr '15

20 Apr '15

I've linked to an ugly attempt to emulate subclasses in Haskell, and I'm wondering if anyone has done what I have perhaps in a cleaner way. Firstly, the code is here: http://ideone.com/znHfSG To explain what I've done, I first thought that a "method" basically takes some "input" (which I've called "i"), an object (which I've called "c" for class) and returns some output "o" and a potentially modified object "c". I've captured this behaviour in the badly named class "C". I've then made a class "User", with methods "getFirstName" and "putFirstName" and defined them appropriately. Furthermore, I've then made a data type "Age", and then "ExtendedUser" which combines "User" with "Age". At this point, I can still call "getFirstName" and "putFirstName" on "ExtendedUser", as would be hoped. I also defined "getAge", which naturally works on ExtendedUser. Furthermore, I can override "getFirstName" on "ExtendedUser", which I have done to instead return a capitalised version. Is what I've done of any practical use? And has someone done it better than me?

4 3

Fall Internship Opportunities at Galois
by Ryan Wright 20 Apr '15

20 Apr '15

Galois has some exciting opportunities for interns in software engineering/research for the Fall of 2015. Most of our projects use Haskell to some extent, so this is a great chance to get experience applying functional programming to important real-world problems. Please pass along this posting to anyone you think might be interested--even if they don't yet know Haskell! Thank you, Ryan Wright — # Galois Software Engineering/Research Intern # Galois is currently seeking software engineering and research interns for Fall 2015 at all educational levels. We are committed to matching interns with exciting and engaging engineering work that fits their particular interests, creating lasting value for interns, Galois, and our community. A Galois internship is a chance to tackle cutting-edge, meaningful problems in a uniquely collaborative environment with world-leading researchers. Roles may include technology research and development, requirements gathering, implementation, testing, formal verification, and infrastructure development. Past interns have integrated formal methods tools into larger projects, built comprehensive validation suites, synthesized high-performance cryptographic algorithms, written autopilots for quad-copters, designed the syntax and semantics of scripting languages, and researched type system extensions for academic publication. We deeply believe in providing comprehensive support and mentorship to all of our employees, particularly interns. We provide our employees with a steward who regularly checks in to ensure that they feel welcome and safe in the Galois community while gaining real value from their experiences. ## Important Dates ## Applications due: June 1st, 2015 Internship period (flexible): September through December, 2015 ## About Galois ## Our mission is to create trustworthiness in critical systems. We’re in the business of taking blue-sky ideas and turning them into real-world technology solutions. We’ve been developing real-world systems for over ten years using functional programming, language design, and formal methods. Galois values diversity. We believe that differing viewpoints and experiences are essential to the process of innovation. We look broadly, including outside of established communities, to deliver innovation. ## How to Prepare ## An internship is an opportunity for learning and growth as an engineer. To make the most of the opportunity, we ask that candidates have experience reading, writing, and maintaining code in a realistic project. Many university courses involve multi-week collaborative projects that provide this type of experience. Most of our projects use the Haskell programming language and the git version control system. These tools aren’t often taught in computer science classes, but there are many free resources available that we recommend for learning: - [Learn You a Haskell] for Great Good! [1] by Miran Lipovača - [Real World Haskell] [2] by Bryan O’Sullivan, Don Stewart, and John Goerzen - [tryGit] [3] by Code School - [Pro Git] [4] by Scott Chacon [1]: http://learnyouahaskell.com/ [2]: http://book.realworldhaskell.org/ [3]: http://try.github.io [4]: http://git-scm.com/book ## Qualifications ## The ability to be geographically located in Portland during the internship Experience reading, writing, and maintaining code in a project as described above Proficiency in software development practices such as design, documentation, testing, and the use of version control Well-developed verbal and written communication skills; comfort in a collaborative team environment The following skills are not required, but may be relevant to a particular project. - Proficiency in Haskell or other programming languages with rich type systems (eg., Scala, OCaml, Standard ML) - Experience using C and assembly languages for low-level systems programming - Development experience in high assurance systems or security software - Specific experience in an area of Galois’ expertise, such as: - Assured information sharing - Software modeling and formal verification - Cyber-physical systems and control systems - Operating systems, virtualization and secure platforms - Networking and mobile technology - Cyber defense systems - Scientific computing - Program analysis and software evaluation - Web security ## Logistics ## The length and start date of the internship are negotiable: starting any time from the new year through next spring is acceptable, but an intern must be at Galois for at least three continuous months. The internship is paid competitively, and interns are responsible for living arrangements (although we can certainly help you find arrangements). Galois is located in the heart of downtown Portland with multiple public transportation options available and world-class bicycle infrastructure. ## Application Details ## We’re looking for people who can invent, learn, think, and inspire. We reward creativity and thrive on collaboration. If you are interested, please send your cover letter and resume to us via http://galois-inc.hiringthing.com.

1 0

New Functional Programming Job Opportunities
by Functional Jobs 20 Apr '15

20 Apr '15

Here are some functional programming job opportunities that were posted recently: Mid/Senior Software Development Engineer at Lookingglass Cyber Solutions http://functionaljobs.com/jobs/8810-mid-senior-software-development-enginee… Senior/Principal Software Development Engineer at Lookingglass Cyber Solutions http://functionaljobs.com/jobs/8809-senior-principal-software-development-e… Cheers, Sean Murphy FunctionalJobs.com

1 0

Maintenance of feed package
by Adam Bergmark 20 Apr '15

20 Apr '15

Hi café, Sigbjorn. I emailed Sigbjorn a week ago asking whether he was still maintaining the `feed' package. I haven't received a reply, and I haven't been able to find any sign of him online recently. Unless he resurfaces I'd like to take over as maintainer of the package to publish the changes required for GHC 7.10 compatibility and other dependencies that have fallen out of date. See: https://github.com/sof https://github.com/sof/feed/pulls https://github.com/haskell-infra/hackage-trustees/issues/12 Regards, Adam

2 1

ANN: hsreadability-1.0.0
by Alexey Shmalko 19 Apr '15

19 Apr '15

I'm pleased to announce the first release of hsreadability: Haskell bindings to the Readability API [1]. The Readability provides three services for developers: Reader, Parser and Shortener: - Reader provides access to the user's info, bookmarks, articles and tags; - Parser is an interface to the powerful web content parser; - Shortener is a URL shortener (doesn't require authentication). With hsreadability you're able to access all the functionality of these services from Haskell. If you have any issues, report them on the GitHub page [2]. I'd also love to hear any other feedback so feel free to comment here or email me. Best regards, Alexey Shmalko [1] https://readability.com/developers/api [2] https://github.com/rasendubi/hsreadability

1 0

Scala at position 25 of the Tiobe index, Haskell dropped below 50
by Henk-Jan van Tuyl 19 Apr '15

19 Apr '15

L.S., From the Tiobe index page[0] of this month: Another interesting move this month concerns Scala. The functional programming language jumps to position 25 after having been between position 30 and 50 for many years. Scala seems to be ready to enter the top 20 for the first time in history. Haskell dropped from the top 50 last month and hasn't come back. I suppose, if Haskell compiled to JVM, Haskell would have a much wider audience. Regards, Henk-Jan van Tuyl [0] http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

8 8

dependency issues on a new install of haskell-platform 2014.2.0.0 64bit on OSX
by Anatoly Yakovenko 18 Apr '15

18 Apr '15

so I keep seeing failures in some modules, but if i install them by hand things get resolved. How do i get cabal to do this for me? so the dependencies: criterion -> monad-par-0.3.4.7 -> parallel-3.2.0.4 which fails but installing parallel-3.2.0.6 unravels the broken dependency chain. Below is the output: cabal: Error: some packages failed to install: criterion-1.1.0.0 depends on monad-par-0.3.4.7 which failed to install. monad-par-0.3.4.7 failed during the building phase. The exception was: ExitFailure 1 statistics-0.13.2.3 depends on monad-par-0.3.4.7 which failed to install. anatolys-MacBook:rbm anatolyy$ cabal install monad-par Resolving dependencies... Configuring monad-par-0.3.4.7... Building monad-par-0.3.4.7... Failed to install monad-par-0.3.4.7 Last 10 lines of the build log ( /Users/anatolyy/.cabal/logs/monad-par-0.3.4.7.log ): Building monad-par-0.3.4.7... Preprocessing library monad-par-0.3.4.7... <command line>: cannot satisfy -package-id parallel-3.2.0.4-c330f8c64fe6816637464ee78fcb9a93 (use -v for more information) cabal: Error: some packages failed to install: monad-par-0.3.4.7 failed during the building phase. The exception was: ExitFailure 1 anatolys-MacBook:rbm anatolyy$ cabal install parallel Resolving dependencies... Downloading parallel-3.2.0.6... Configuring parallel-3.2.0.6... Building parallel-3.2.0.6... Installed parallel-3.2.0.6 Updating documentation index /Users/anatolyy/Library/Haskell/share/doc/index.html anatolys-MacBook:rbm anatolyy$ cabal install monad-par Resolving dependencies... Configuring monad-par-0.3.4.7... Building monad-par-0.3.4.7... Installed monad-par-0.3.4.7 Updating documentation index /Users/anatolyy/Library/Haskell/share/doc/index.html

1 0

Re: [Haskell-cafe] Graph diagram tools?
by Ivan Lazar Miljenovic 17 Apr '15

17 Apr '15

Wow, you really have resurrected an old thread! On 17 April 2015 at 03:12, Ivan Zakharyaschev <imz(a)altlinux.org> wrote: > Hi, > > I have some feedback on the API of the graphviz library's monadic API > (resulting form my explorations written down at > http://mathoverflow.net/a/203099/13991 ). > > Le jeudi 23 juin 2011 04:38:21 UTC+4, Ivan Lazar Miljenovic a écrit : >> >> On 23 June 2011 02:48, Stephen Tetley <stephen...(a)gmail.com> wrote: >> > Or Andy Gill's Dotgen - simple and stable: >> > >> > http://hackage.haskell.org/package/dotgen >> >> Within the next month, I should hopefully finally finish the new >> version of graphviz. Various improvements include: >> >> As such, I would greatly appreciate knowing what it is that makes you >> >> want to use a different library (admittedly the graphviz API isn't as >> stable as the others, but that's because I keep trying to improve it, >> and typically state in the Changelog exactly what has changed). >> >> > > ### graphviz Haskell library and other ones > > An alternative to "graphviz" Haskell package mentioned in > [haskell-cafe](https://groups.google.com/d/msg/haskell-cafe/ZfZaw2E9a18/xZ0O… > is [dotgen](http://hackage.haskell.org/package/dotgen). > > In [a > follow-up](https://groups.google.com/d/msg/haskell-cafe/ZfZaw2E9a18/9P-dazc… > to the post mentioning `dotgen`, the author of graphviz gives some > comparison between them (and other similar Haskell libs). I assume his > "plans" (about a monadic interface) have been implemented already: Yup: http://hackage.haskell.org/package/graphviz-2999.17.0.2/docs/Data-GraphViz-… > >> Within the next month, I should hopefully finally finish the new >> version of graphviz. Various improvements include: >> >> ... >> >> * A Dot graph representation based loosely upon **dotgen**'s monadic >> interface (with Andy's blessing) but with the various Attributes being >> used rather than (String, String). I think I'm going to be able to >> make it such that you can define a graph using the monadic interface >> that will almost look identical to actual Dot code. >> >> ... >> >> I would like to stress to people considering using other bindings to >> Graphviz/Dot (such as **dotgen**, language-dot, or their own >> cobbled-together interface): be very careful about quoting, etc. I >> have spent a _lot_ of time checking how to properly escape different >> values and ensuring correctness under the hood (i.e. there is no need >> to pre-escape your Text/String values; graphviz will do that for you >> when generating the actual Dot code). This, after all, is the point >> of having existing libraries rather than rolling your own each time. > > Both points are related. (So, graphviz's monadic iterface is a safer > improvement upon dotgen's one.) > > ### Considering dotgen vs graphviz closer > > But looking into the examples, I see that `dotgen` can use "Haskell > ids" to identify created nodes, whereas in graphviz's monad (see the > example above) one must supply extra strings as the unique ids (by > which we refer to the nodes). I used Strings as an example, as I was directly converting an existing piece of Dot code; the original can be found here: http://hackage.haskell.org/package/graphviz-2999.17.0.2/docs/Data-GraphViz-… But, you can use any type you like for the node identifiers, as long as you make them an instance of the PrintDot class. That's where the `n` in the `Dot n` type comes in. > > I like the first approach more ("Haskell ids"). I admittedly don't have any ability in graphviz to create new identifiers for you. I could (just add a StateT to the internal monadic stack which keeps track of the next unused node identifier) but I think that would _reduce_ the flexibility of being able to use your own type (it would either only work for `Dot Int`, or even if you could apply a mapping function to use something like `GraphID`, but that has a problem if you have a `Double` with the same value - and hence same textual representation - as your Int). The way I see it, graphviz is usually used for converting existing Haskell values into Dot code and then processing with dot, neato, etc. the Monadic interface exists so that you can still use the library for static pre-specified graphs (I wrote the module for a specific use case, but in practice found it not as useful as I thought it would be as I typically don't have a need for static graphs in my Haskell code). > > Cf. dotgen (from > <https://github.com/ku-fpg/dotgen/blob/master/test/DotTest.hs>): > > module Main (main) where > import Text.Dot > -- data Animation = Start > src, box, diamond :: String -> Dot NodeId > src label = node $ [ ("shape","none"),("label",label) ] > box label = node $ [ ("shape","box"),("style","rounded"),("label",label) > ] > diamond label = node $ > [("shape","diamond"),("label",label),("fontsize","10")] > main :: IO () > main = putStrLn $ showDot $ do > attribute ("size","40,15") > attribute ("rankdir","LR") > refSpec <- src "S" > tarSpec <- src "T" > same [refSpec,tarSpec] > c1 <- box "S" > c2 <- box "C" > c3 <- box "F" > same [c1,c2,c3] > refSpec .->. c1 > tarSpec .->. c2 > tarSpec .->. c3 > m1 <- box "x" > m2 <- box "y" > ntm <- box "z" > same [m1,m2,ntm] > c1 .->. m1 > c2 .->. m2 > xilinxSynthesis <- box "x" > c3 .->. xilinxSynthesis > gns <- box "G" > xilinxSynthesis .->. gns > gns .->. ntm > ecs <- sequence > [ diamond "E" > , diamond "E" > , diamond "Eq" > ] > same ecs > m1 .->. (ecs !! 0) > m1 .->. (ecs !! 1) > m2 .->. (ecs !! 0) > m2 .->. (ecs !! 2) > ntm .->. (ecs !! 1) > ntm .->. (ecs !! 2) > _ <- sequence [ do evidence <- src "EE" > n .->. evidence > | n <- ecs > ] > edge refSpec tarSpec > [("label","Engineering\nEffort"),("style","dotted")] > () <- scope $ do v1 <- box "Hello" > v2 <- box "World" > v1 .->. v2 > (x,()) <- cluster $ > do v1 <- box "Hello" > v2 <- box "World" > v1 .->. v2 > -- x .->. m2 > -- for hpc > () <- same [x,x] > v <- box "XYZ" > v .->. v > () <- attribute ("rankdir","LR") > let n1 = userNodeId 1 > let n2 = userNodeId (-1) > () <- n1 `userNode` [ ("shape","box")] > n1 .->. n2 > _ <- box "XYZ" > _ <- box "(\n\\n)\"(/\\)" > netlistGraph (\ a -> [("label","X" ++ show a)]) > (\ a -> [succ a `mod` 10,pred a `mod` 10]) > [ (n,n) | n <- [0..9] :: [Int] ] > return () > My preference - and hence overall design with graphviz - is that you would generate the graph first, and _then_ convert it to a Dot representation en masse. > > Cf. graphviz with string ids: > > A short example of the monadic notation from [the > documentation](http://hackage.haskell.org/package/graphviz-2999.16.0.0/docs…: That version is a tad out of date, but shouldn't affect this. > > digraph (Str "G") $ do > > cluster (Int 0) $ do > graphAttrs [style filled, color LightGray] > nodeAttrs [style filled, color White] > "a0" --> "a1" > "a1" --> "a2" > "a2" --> "a3" > graphAttrs [textLabel "process #1"] > > cluster (Int 1) $ do > nodeAttrs [style filled] > "b0" --> "b1" > "b1" --> "b2" > "b2" --> "b3" > graphAttrs [textLabel "process #2", color Blue] > > "start" --> "a0" > "start" --> "b0" > "a1" --> "b3" > "b2" --> "a3" > "a3" --> "end" > "b3" --> "end" > > node "start" [shape MDiamond] > node "end" [shape MSquare] > > Thanks for the packages, and best wishes, > Ivan Z. -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

2 2

Re: [Haskell-cafe] Scala at position 25 of the Tiobe index, Haskell dropped
by Gregory Guthrie 17 Apr '15

17 Apr '15

I find that Haskell has a very different learning curve from other languages that I use/know/have-tried, in that the basic language itself is very simple and easy to learn and appreciate. However once one starts using a lot of monads and applicatives and other libraries, it can begin to look more like APL. >>> parser >>= >>> ( \s -> return ( pl' { P.payloadData = setField pld (Just s) } } ) ) Certainly one can learn to parse and read this, but with all of the new operators and thus syntax not familiar to standard IP language users. (Not a complaint, just an observation from teaching this to students new to FP.) And in my experience the cabal problems are the "fatal-flaw"; it is not infrequent that I have had to delete all libraries and start over, and I have only very simple usage. I would not want to have a business project that depended on this, as often I have not found a good solution where I could install all the packages I wanted. (Perhaps I just need to learn more about sandboxing techniques.) I am not a fan of the Scala syntax, but it does seem to be an easier transition because it look-and-feel's more like the typical IPs. ------------------------------------------- > -----Original Message----- ...

6 8

Re: [Haskell-cafe] [Haskell-beginners] texture mapping with SDL
by Sumit Sahrawat, Maths & Computing, IIT (BHU) 17 Apr '15

17 Apr '15

On 17 April 2015 at 19:28, Florian Gillard <florian.gillard(a)gmail.com> wrote: > Hi everyone, > > I am not sure my previous message went trough, if so, sorry for the double > post. > > I am trying to make a basic raycaster (something like the first > wolfenstein 3D) using haskell and SDL 1.2 > > So far I have it working using coloured lines and I would like to know if > there is any way to apply transforms to textures loaded in memory using > SDL, in order to achieve basic texture mapping on the walls. > > I looked at the SDL doc but I didn't find anything looking like what I > need. > > The code is there: > > https://github.com/eniac314/maze-generator/blob/master/raycaster.hs > > sreenshot here: > https://github.com/eniac314/maze-generator/blob/master/raycaster.png > > (the last part is not done yet but has nothing to do with the raycaster) > > I would appreciate any suggestion :) > > _______________________________________________ > Beginners mailing list > Beginners(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > The message got through. It might be better answered on the haskell-cafe so I'm relaying it there. -- Regards Sumit Sahrawat

1 0

Coding katas/dojos and functional programming introduction
by Gautier DI FOLCO 17 Apr '15

17 Apr '15

Hello, Some days ago I have participated to a coding dojo* which aimed to be an introduction to functional programming. I have also facilitate 3 of events like this and do several talks on this subject. But I'm kinda disappointed because each time there is a common pattern: 1. Unveil the problem which will be treated 2. Let the attendees solve it 3. Show the FP-ish solution (generally a bunch of map/fold) I think it's frustrating for the attendees (because they don't try to solve it) and gives a false illusion of knowledge. I don't consider myself as a "FP guru" or anything but for me FP is a matter of types and expressions, so when someone illustrate FP via map/fold, it's kind of irritating. Ironically, the best workshop I have done was on functional generalization (you begin by two hard coded functions, sum and product, and you extract Foldable and Monoid), but again, it's not satisfying. We can do better, we should do better. Have you got any feedback/subjet ideas/examples on how to introduce "real" FP to beginners in a short amount of time (like 1-3 hours)? Thanks in advance for your help. Regards. * Basically you have 2 to 3 hours, a problem and you try to solve with in iteration with different constraints

7 9

Ongoing IHG work to improve Hackage security
by Duncan Coutts 17 Apr '15

17 Apr '15

All, The IHG members identified Hackage security as an important issue some time ago and myself and my colleague Austin have been working on a design and implementation. The details are in this blog post: http://www.well-typed.com/blog/2015/04/improving-hackage-security We should have made more noise earlier about the fact that we're working on this. We saw that it was important to finally write this up now because other similar ideas are under active discussion and we don't want to cause too much unnecessary duplication. The summary is this: We're implementing a system to significantly improve Hackage security. It's based on a sensible design (The Update Framework) by proper crypto experts. The basic system is fully automatic and covers all packages on Hackage. A proposed extension would give further security improvements for individual packages at the cost of a modest effort from package authors. http://theupdateframework.com/ It will also allow the secure use of untrusted public Hackage mirrors, which is the simplest route to better Hackage reliability. As a bonus we're including incremental index downloads to reduce `cabal update` wait times. And it's all fully backwards compatible. I should also note that our IHG funding covers the first phase of the design, and for the second phase we would very much welcome others to get involved with the detailed design and implementation (or join the IHG and contribute further funding). -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 5

Execution order in IO
by Jon Schneider 17 Apr '15

17 Apr '15

Good morning all, I think I've got the hang of the way state is carried and fancy operators work in monads but still have a major sticky issue. With lazy evaluation where is it written that if you write things with no dependencies with a "do" things will be done in order ? Or isn't it ? Is it a feature of the language we're supposed to accept ? Is it something in the implementation of IO ? Is the do keyword more than just a syntactic sugar for a string of binds and lambdas ? Jon

14 22

Advice needed on how to improve some code
by Jeff 16 Apr '15

16 Apr '15

Hello, I am seeking some advice on how I might improve a bit of code. The function in question reads and parses part of a binary protocol, storing the parsed info as it proceeds. parseDeviceData is called by parseDevice (shown further down). It looks to me like there should be a more concise, less repetitive way to do what parseDeviceData does. Any advice on this would be greatly appreciated. parseDeviceData :: P.Payload -> Parser P.Payload parseDeviceData pl = let mdm = P.dataMask ( P.payloadData pl ) in ( let pld = P.payloadData pl in if testBit mdm ( fromEnum D.Sys ) then parseDeviceSysData >>= ( \s -> return ( pl { P.payloadData = pld { P.sysData = Just s } } ) ) else return pl ) >>= ( \pl' -> let pld = P.payloadData pl' in if testBit mdm ( fromEnum D.GPS ) then parseDeviceGPSData >>= ( \s -> return ( pl' { P.payloadData = pld { P.gpsData = Just s } } ) ) else return pl' ) >>= ( \pl' -> let pld = P.payloadData pl' in if testBit mdm ( fromEnum D.GSM ) then parseDeviceGSMData >>= ( \s -> return ( pl' { P.payloadData = pld { P.gsmData = Just s } } ) ) else return pl' ) >>= ( \pl' -> let pld = P.payloadData pl' in if testBit mdm ( fromEnum D.COT ) then parseDeviceCOTData >>= ( \s -> return ( pl' { P.payloadData = pld { P.cotData = Just s } } ) ) else return pl' ) >>= ( \pl' -> let pld = P.payloadData pl' in if testBit mdm ( fromEnum D.ADC ) then parseDeviceADCData >>= ( \s -> return ( pl' { P.payloadData = pld { P.adcData = Just s } } ) ) else return pl' ) >>= ( \pl' -> let pld = P.payloadData pl' in if testBit mdm ( fromEnum D.DTT ) then parseDeviceDTTData >>= ( \s -> return ( pl' { P.payloadData = pld { P.dttData = Just s } } ) ) else return pl' ) >>= ( \pl' -> let pld = P.payloadData pl' in if testBit mdm ( fromEnum D.OneWire ) then parseDeviceOneWireData >>= ( \s -> return ( pl' { P.payloadData = pld { P.iwdData = Just s } } ) ) else return pl' ) >>= ( \pl' -> if testBit mdm ( fromEnum D.ETD ) then parseDeviceEventData pl' else return pl' ) The Parser above is a Data.Binary.Strict.Get wrapped in a StateT, where the state is a top-level structure for holding the parsed packet. parseDevice :: Bool -> Parser () parseDevice _hasEvent = parseTimestamp >>= ( \ts -> if _hasEvent then lift getWord8 >>= ( \e -> lift getWord16be >>= ( \mdm -> return ( P.Payload "" ( Just ts ) $ P.blankDevicePayloadData { P.dataMask = mdm , P.eventID = toEnum ( fromIntegral e .&. 0x7f ) , P.deviceStatusFlag = testBit e 7 , P.hasEvent = True } ) ) ) else lift getWord16be >>= ( \mdm -> return ( P.Payload "" ( Just ts ) $ P.blankDevicePayloadData { P.dataMask = mdm } ) ) ) >>= parseDeviceData >>= ( \dpl -> get >>= ( \p -> put ( p { P.payloads = dpl : P.payloads p } ) ) ) Here are the data types for the Packet and Payload: data Payload = Payload { imei :: !BS.ByteString , timestamp :: Maybe Word64 , payloadData :: PayloadData } data PayloadData = HeartBeatPL | SMSFwdPL { smsMesg :: !BS.ByteString } | SerialPL { auxData :: !Word8 , fixFlag :: !Word8 , gpsCoord :: !GPSCoord , serialData :: !BS.ByteString } | DevicePL { hasEvent :: !Bool , deviceStatusFlag :: !Bool , eventID :: !E.EventID , dataMask :: !Word16 , sysData :: Maybe DS.SysData , gpsData :: Maybe DGP.GPSData , gsmData :: Maybe DGS.GSMData , cotData :: Maybe DC.COTData , adcData :: Maybe DA.ADCData , dttData :: Maybe DD.DTTData , iwdData :: Maybe DO.OneWireData , etdSpd :: Maybe ES.SpeedEvent , etdGeo :: Maybe EG.GeoEvent , etdHealth :: Maybe EH.HealthEvent , etdHarsh :: Maybe EHD.HarshEvent , etdOneWire :: Maybe EO.OneWireEvent , etdADC :: Maybe EA.ADCEvent } deriving ( Show ) data Packet = Packet { protocolVersion :: !Word8 , packetType :: !PT.PacketType , deviceID :: Maybe BS.ByteString , payloads :: ![ Payload ] , crc :: !Word16 } deriving ( Show ) Lastly, here is the Parser monad transformer: module G6S.Parser where import Control.Monad.State.Strict import Data.Binary.Strict.Get import qualified Data.ByteString as BS import qualified G6S.Packet as GP type Parser = StateT GP.Packet Get runParser :: Parser a -> BS.ByteString -> Maybe a runParser p bs = let ( result, _ ) = runGet ( runStateT p GP.initPacket ) bs in case result of Right tup -> Just $ fst tup Left _ -> Nothing I hope there is enough info here. Thanks, Jeff

6 10

Re: [Haskell-cafe] Ongoing IHG work to improve Hackage security
by Mikhail Glushenkov 16 Apr '15

16 Apr '15

Hi, On 16 April 2015 at 16:08, Herbert Valerio Riedel <hvriedel(a)gmail.com> wrote: > Being historically a tape-originating archive format, `tar` does support > such destructive updates as a standard-feature by appended content. Thanks, I understand this. My question was about whether cabal-install supports this feature of tar (turns out, it does). > Using this, we can actually have *all* historic .cabal revisions in the > 00-index.tar file as hidden entries. I don't think we do this right now, though.

1 0

Re: [Haskell-cafe] Ongoing IHG work to improve Hackage security
by Duncan Coutts 16 Apr '15

16 Apr '15

On Thu, 2015-04-16 at 16:08 +0200, Herbert Valerio Riedel wrote: > On 2015-04-16 at 15:14:47 +0200, Mikhail Glushenkov wrote: > > [...] > > > Thank you, this is very exciting. But won't the post-release .cabal > > update feature interfere with "package index as an append-only log" > > concept? IIUC, right now it is implemented as a destructive update of > > the corresponding package index entry, so making the package index > > immutable will break backwards compatibility. > > Being historically a tape-originating archive format, `tar` does support > such destructive updates as a standard-feature by appended content. See > also the '--update' operation in the tar(1) man-page: > > | -u, --update > | Append files which are newer than the corresponding copy in > | the archive. Arguments have the same meaning as with -c and > | -r options. > > Using this, we can actually have *all* historic .cabal revisions in the > 00-index.tar file as hidden entries. This would in theory give > `cabal-install` access to all cabal revisions (if we'd ever want to have > a feature in cabal that requires access to previous cabal revisions) Yes, we can choose to do that. That's sort-of what I was getting at when I mentioned that you could then view the tar file as a transaction log. > I actually find Duncan's approach rather elegant, as it simply builds on > existing standard features of both .tar files and the HTTP protocol > (resuming HTTP downloads). And they don't even require any custom HTTP > server implementation to work, and there's a graceful fallback. And we > don't need to introduce a completely new protocol/tool into the mix > (such as Git, which has dump-http(s), smart-http(s), git, as > transport-layers to chose from, and has various other moving parts such > as a ~/.gitconfig that can affect how Git operates, like redirecting > clone-urls transparently, also it avoids having to handle subtle > platform-specific issues with shelling out to an external command; from > this POV the HTTP/tar approach is the more KISS-compliant one, IMHO) > > Cheers, > hvr >

1 0

Re: [Haskell-cafe] Improvements to package hosting and security
by Michael Snoyman 16 Apr '15

16 Apr '15

That could work in theory. My concern with such an approach is that- AFAIK- the tooling around that kind of stuff is not very well developed, as opposed to an approach using Git, SHA512, and GPG, which should be easy to combine. But I could be completely mistaken on this point; if existing, well vetted technology exists for this, I'm not opposed to using it. On Mon, Apr 13, 2015 at 6:04 PM Arnaud Bailly | Capital Match < arnaud(a)capital-match.com> wrote: > Just thinking aloud but wouldn't it be possible to take advantage of > cryptographic ledgers a la Bitcoin for authenticating packages and tracking > the history of change ? This would provide redundancy as the transactions > log is distributed and "naturally" create a web of trust or at least > authenticate transactions. People uploading or modifying a package would > have to sign a transactions with someone having enough karma to allow this. > > Then packages themselves could be completely and rather safely distributed > through standard p2p file sharing. > > I am not a specialist of crypto money, though. > > My 50 cts > Arnaud > > Le lundi 13 avril 2015, Dennis J. McWherter, Jr. <dennis(a)deathbytape.com> > a écrit : > >> This proposal looks great. The one thing I am failing to understand (and >> I recognize the proposal is in early stages) is how to ensure redundancy in >> the system. As far as I can tell, much of this proposal discusses the >> centralized authority of the system (i.e. ensuring secure distribution) and >> only references (with little detail) the distributed store. For instance, >> say I host a package on a personal server and one day I decide to shut that >> server down; is this package now lost forever? I do see this line: "backup >> download links to S3" but this implies that the someone is willing to pay >> for S3 storage for all of the packages. >> >> Are there plans to adopt a P2P-like model or something similar to support >> any sort of replication? Public resources like this seem to come and go, so >> it would be nice to avoid some of the problems associated with high churn >> in the network. That said, there is an obvious cost to replication. >> Likewise, the central authority would have to be updated with new, relevant >> locations to find the file (as it is currently proposed). >> >> In any case, as I said before, the proposal looks great! I am looking >> forward to this. >> >> On Monday, April 13, 2015 at 5:02:46 AM UTC-5, Michael Snoyman wrote: >>> >>> Many of you saw the blog post Mathieu wrote[1] about having more >>> composable community infrastructure, which in particular focused on >>> improvements to Hackage. I've been discussing some of these ideas with both >>> Mathieu and others in the community working on some similar thoughts. I've >>> also separately spent some time speaking with Chris about package >>> signing[2]. Through those discussions, it's become apparent to me that >>> there are in fact two core pieces of functionality we're relying on Hackage >>> for today: >>> >>> * A centralized location for accessing package metadata (i.e., the cabal >>> files) and the package contents themselves (i.e., the sdist tarballs) >>> * A central authority for deciding who is allowed to make releases of >>> packages, and make revisions to cabal files >>> >>> In my opinion, fixing the first problem is in fact very straightforward >>> to do today using existing tools. FP Complete already hosts a full Hackage >>> mirror[3] backed by S3, for instance, and having the metadata mirrored to a >>> Git repository as well is not a difficult technical challenge. This is the >>> core of what Mathieu was proposing as far as composable infrastructure, >>> corresponding to next actions 1 and 3 at the end of his blog post (step 2, >>> modifying Hackage, is not a prerequesite). In my opinion, such a system >>> would far surpass in usability, reliability, and extensibility our current >>> infrastructure, and could be rolled out in a few days at most. >>> >>> However, that second point- the central authority- is the more >>> interesting one. As it stands, our entire package ecosystem is placing a >>> huge level of trust in Hackage, without any serious way to vet what's going >>> on there. Attack vectors abound, e.g.: >>> >>> * Man in the middle attacks: as we are all painfully aware, >>> cabal-install does not support HTTPS, so a MITM attack on downloads from >>> Hackage is trivial >>> * A breach of the Hackage Server codebase would allow anyone to upload >>> nefarious code[4] >>> * Any kind of system level vulnerability could allow an attacker to >>> compromise the server in the same way >>> >>> Chris's package signing work addresses most of these vulnerabilities, by >>> adding a layer of cryptographic signatures on top of Hackage as the central >>> authority. I'd like to propose taking this a step further: removing Hackage >>> as the central authority, and instead relying entirely on cryptographic >>> signatures to release new packages. >>> >>> I wrote up a strawman proposal last week[5] which clearly needs work to >>> be a realistic option. My question is: are people interested in moving >>> forward on this? If there's no interest, and everyone is satisfied with >>> continuing with the current Hackage-central-authority, then we can proceed >>> with having reliable and secure services built around Hackage. But if >>> others- like me- would like to see a more secure system built from the >>> ground up, please say so and let's continue that conversation. >>> >>> [1] https://www.fpcomplete.com/blog/2015/03/composable- >>> community-infrastructure >>> [2] https://github.com/commercialhaskell/commercialhaskell/wiki/ >>> Package-signing-detailed-propsal >>> [3] https://www.fpcomplete.com/blog/2015/03/hackage-mirror >>> [4] I don't think this is just a theoretical possibility for some point >>> in the future. I have reported an easily trigerrable DoS attack on the >>> current Hackage Server codebase, which has been unresolved for 1.5 months >>> now >>> [5] https://gist.github.com/snoyberg/732aa47a5dd3864051b9 >>> >> -- >> > You received this message because you are subscribed to the Google Groups >> "Commercial Haskell" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to commercialhaskell+unsubscribe(a)googlegroups.com. >> To post to this group, send email to commercialhaskell(a)googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/commercialhaskell/4487776e-b862-429c-adae… >> <https://groups.google.com/d/msgid/commercialhaskell/4487776e-b862-429c-adae…> >> . > > >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > *Arnaud Bailly* > > CTO | Capital Match > > CapitalMatch > > 71 Ayer Rajah Crescent | #06-16 | Singapore 139951 > > (FR) +33 617 121 978 / (SG) +65 8408 7973 | arnaud(a)capital-match.com | > www.capital-match.com > > Disclaimer: > > *Capital Match Platform Pte. Ltd. (the "Company") registered in Singapore > (Co. Reg. No. 201501788H), a subsidiary of Capital Match Holdings Pte. Ltd. > (Co. Reg. No. 201418682W), provides services that involve arranging for > multiple parties to enter into loan and invoice discounting agreements. The > Company does not provide any form of investment advice or recommendations > regarding any listings on its platform. In providing its services, the > Company's role is limited to an administrative function and the Company > does not and will not assume any advisory, fiduciary or other duties to > clients of its services.* > >

8 24

FunDeps and type inference
by Olaf Klinke 15 Apr '15

15 Apr '15

Dear cafe, I want to write an evaluation function that uncurries its function argument as necessary. Examples should include: eval :: (a -> b) -> a -> b eval :: (a -> b -> c) -> a -> (b -> c) eval :: (a -> b -> c) -> (a,b) -> c and hence have both eval (+) 4 5 eval (+) (4,5) typecheck. My approach is to use a type class: class Uncurry f a b where eval :: f -> a -> b instance Uncurry (a -> b) a b where eval = ($) instance (Uncurry f b c) => Uncurry ((->) a) f) (a,b) c where eval f (a,b) = eval (f a) b This works, but not for polymorphic arguments. One must annotate function and argument with concrete types when calling, otherwise the runtime does not know what instance to use. Type inference on ($) is able to infer the type of either of f, a or b in the expression b = f $ a if the type of two is known. Thus I am tempted to add functional dependencies class Uncurry f a b | f a -> b, a b -> f, f b -> a but I get scary errors: With only the first of the three dependencies, the coverage condition fails. Adding UndecidableInstances, the code compiles. Now type inference on the return type b works, but one can not use e.g. (+) as function argument. Adding the second dependency results in the compiler rejecting the code claiming "Functional dependencies conflict between instance declarations". I can not quite see where they would, and the compiler does not tell me its counterexample. I can see that eval max (True,False) :: Bool -- by second instance declaration, -- when max :: Bool -> Bool -> Bool eval max (True,False) :: (Bool,Bool) -> (Bool,Bool) -- by first instance declaration -- when max :: (Bool,Bool) -> (Bool,Bool) -> (Bool,Bool) but this ambiguity is precisely what the dependency a b -> f should help to avoid, isn't it? Judging by the number of coverage condition posts on this list this one is easy to get wrong and the compiler messages are not always helpful. Is this a kind problem? Would anyone care to elaborate? Thanks, Olaf

2 1

Why no Floating instance for Data.Fixed / Data.Fixed.Binary
by Douglas McClean 15 Apr '15

15 Apr '15

I'm wondering why the decision was made not to have a Floating instance for Data.Fixed. I understand that -- being a fixed point number type -- it doesn't line up with the name of the Floating typeclass. But it also seems that Floating is misnamed, because none of the functions there really have anything to do with floating point representation. This is why we still have Floating instances for, say, exact reals or symbolic numbers, neither of which has a floating point representation. It seems that the actual criterion for membership in Floating is something like "has a canonical choice for degree of approximation". Double and Float are in because we round to the nearest value. Exact reals are in because we don't have to approximate, symbolic numbers too. Rational is out because there's no clear choice of how to approximate. But by this criterion, Data.Fixed should be in. And indeed it would be useful for it to be in. If I choose to represent values from the real world by a fixed point approximation instead of a floating point approximation, shouldn't I still be able to take sines and cosines etc? Obviously I can fix this by using a newtype. I'm just curious if am I missing a reason why the current definition is more desirable? -Doug McClean

3 4

Do all "fromList" functions redirect to List operations?
by martin 14 Apr '15

14 Apr '15

Hello all, I have a datatype like this: data Time = DPast | T Integer deriving (Eq, Show) data Temporal a = Temporal { at :: Time -> (a, Maybe Time) } and I wrote a fromList function to create one. The fromList function implements it own "at" function and wraps it in a Temporal. IIUC, this means that whenever I invoke "at" on a Temporal created from a List I actually operate on that List. Alternatively I can directly create a Temporal as in exNat = Temporal f where f DPast = (0, Just $ T 1) f (T t) = (t, Just $ T $ t+1) whose "at" function is a lot faster. Do all "fromList" functions behave this way, i.e. they redirect operations on the new type to List operations? Is there a way to make a Temporal, created via fromList "forget" its List heritage?

1 0

Eta-reducing case branches
by Tom Ellis 14 Apr '15

14 Apr '15

Has anyone ever considered permitting case branches to be eta reduced? For example, it is often nice to rewrite foo x = bar baz x as foo = bar baz Likewise, I have often wanted to rewrite case m of Nothing -> n Just x -> quux x as case m of Nothing -> n Just -> quux Am I missing an obvious reason this wouldn't work? Tom

4 4

Re: [Haskell-cafe] Help wanted: working on the GHC webpage
by Sergey Bushnyak 14 Apr '15

14 Apr '15

> Why would it be easier? What's difficult about publishing on > https://ghc.haskell.org/trac/ghc/blog? I'm actually don't know how it's published on track. From my standpoint as newcomer it's better to see what's happening from one place, with one design, have some shared git repo where people contribute in markdown. > Moreover, the GHC weekly news are intimately linked to Trac, as they > reference Trac-tickets and Git commits, which Trac is able to annotate > with meta-data (ticket-type, -status, and -title for Ticket references, > as well as part of the Git commit msg for Git-commit refs). Ok, it was just a suggestion. Maybe it's a bad idea, doesn't know about annotation. Anyway, still can help on updating ghc home page.

2 1

Semantics of temporal data
by martin 14 Apr '15

14 Apr '15

Hello all, I wrote a Temporal datatype data Temporal a = Temporal { td :: a, -- "temporal default" tc :: [Change a] -- "temporal changes" } deriving (Eq, Show) data Change a = Chg { ct :: Time, -- "change time" cv :: a -- "change value" } deriving (Eq,Show) I got into semantic trouble when trying to write "join" for Temporal (Temporal a). If I have a Temporal Temporal, then each change's value is a Temporal. The question is: what significance does the temporal default have? In my implementation, when I look at this Chg t0 (Temporal default0 changes0) Chg t1 (Temporal default1 changes1) --<-- you are here Chg t2 (Temporal default2 changes2) I accept the changes1 which are >= t1 and less than t2. So far so good. But I also take the default1 and prepend it to the resuling list of changes with a change time of t1 (unless the first of the changes1 occurs also at t1). But by comparing results with a handwritten <*>, QuickCheck revealed that this is not in line with <*> = ap x >>= f = join $ fmap f x It appears to me that the defaults of the inner Temporal lose most of their meaning. The effective default is the change value of the last accepted change from the previous (t0) iteration. This would make some sense. If I have a summer schedule which lists the location of a single train over time, and it sais it is usually "nowhere", but at July 1st is shall be in Manchester. If I ask this schedule, where the train will be before July 1st it'll say "nowhere". Now if I prepend the summer schedule with a spring schedule, then there will be a last location of that train in the spring schedule (say Brighton), i.e. before the summer schedule becomes effective. Hence at the beginning of the summer, the train won't be "nowhere" but in Brighton. Does this make some sense? Please feel free to comment. BTW: I am really impressed that haskell pointed out this semantic issue to me. This could have gone unnoticed for months in other languages.

3 4

Anyone interested in taking over network-uri?
by Johan Tibell 14 Apr '15

14 Apr '15

Hi! I find myself with less time to hack lately and I'm trying to reduce the number of libraries I maintain so I can invest time in new things. Would anyone be interested taking over maintenance of network-uri? It should not be much work at all. Bump a few dependencies and fix a bug or two. The package is very widely used so I suggest that the new maintainer should avoid breaking changes whenever possible*. * In other words, if you want to completely rethink network URI handling, this package is probably not the place for it. -- Johan

4 5

Haskell Weekly News
by Kim-Ee Yeoh 14 Apr '15

14 Apr '15

*Top picks:* - Aditya Siram announces the first release of Haskell bindings <http://haskell.1045720.n5.nabble.com/Announcement-FLTKHS-Bindings-to-the-FL…> to the C++-based FLTK cross-platform GUI library. FLTK <http://www.fltk.org/> can be used to build a modern windows-and-widgets-based desktop app and comes with a UI builder called FLUID. - The startup called Helium releases a "homegrown Webmachine-inspired web framework in Haskell." <http://blog.helium.com/helium/2015/04/01/helium-webmachine-airship.html> Airship is very small (just under 1000 LoC) and extremely unopinionated: it works with any WAI-compatible web server and any templating language (including none at all!). Reddit discussion. <http://www.reddit.com/r/haskell/comments/312pk2/haskell_webmachine_airship/> - Adam Chlipala releases a new Ur/Web library for producing custom event-planning web apps <http://www.impredicative.com/pipermail/ur/2015-April/001928.html> quickly. All you need to do is "assemble highly parametrized components." - Abe Voelker <https://blog.abevoelker.com/you-got-haskell-in-my-ruby-cleaner-ruby-validat…> finds himself wanting algebraic data types and pattern matching when writing Ruby. He presents an evolution of a file upload validator, culminating in a finale that uses an Either monad provided by a Ruby gem called Kleisli. - Eitan Chatav shares a correct-by-construction JSON serializer/deserializer <http://lpaste.net/130064> using lens-json. - Wouldn't it be neat to get profiling info without stopping the program and pissing off your users? Mark Wotton <https://ghc.haskell.org/trac/ghc/ticket/10235> has filed exactly such a feature request. - Is Call Arity optimization to blame for your 7.10 compilation slowdowns? Joachim Breitner <http://ghc.haskell.org/trac/ghc/ticket/10293> investigates. - Ever felt Haskell on Windows is 2nd class, even though it's Tier-1 according to the Platform? Well, installing hmatrix on Win requires additional steps, as Redditor wrvn <http://www.reddit.com/r/haskell/comments/322iut/trying_to_install_hmatrix_o…> kindly explains. - Do you program in Haskell using emacs? You must be using haskell-mode then. Here's monthly news <https://github.com/haskell/haskell-mode/wiki/Month-in-haskell-mode-March-20…> straight from the haskell-mode development team. - Dominic Steinitz <http://haskell.1045720.n5.nabble.com/A-Random-Strawman-tp5768239.html> raises awareness about the brokenness of System.Random. Solution? Use tf-random for now. - Big number exponentiation segfaults, in this reddit discussion. <http://www.reddit.com/r/haskell/comments/31yajd/can_you_explain_this/> Turns out it's a bug <https://ghc.haskell.org/trac/ghc/ticket/10282> involving the GNU Multi-precision Library. Make sure you have the latest GMP version 6. - Devan Stormont <https://voyageintech.wordpress.com/2015/04/02/haskell-library-for-forecast-…> creates his first hackage library that obtains weather forecast data via a web-based API. He writes, "The really brilliant part is in being able to completely replace a core piece of an app within a single day and having complete confidence in the result. It’s moments like this that make you really happy to be working with such a powerful language as Haskell." - Carl <http://stackoverflow.com/questions/29455850/pretty-printing-with-free-monad…> reminds us that GADT can always be pattern-matched in a case expression. "It's let expressions that cause GHC to provide amusing messages about its brain exploding." - Zohaib Rauf <http://zohaib.me/yet-another-what-is-a-monad-post/> publishes a monad tutorial. He explains that the 'M' in 'M a' is "some metadata wrapped around 'a'." *Tweets of the week:* - John Carmack: <https://twitter.com/ID_AA_Carmack/status/585871417855516672> If I had to write software that my life depended on, I would seriously consider using Haskell. - shanelogsdon: <https://twitter.com/shanelogsdon/status/586145419639578625> tried the #haskell web framework http://www.spock.li/ last night with a meaningless micro benchmark. ~38k req/s is pretty quick - AlexanderKatt: <https://twitter.com/AlexanderKatt/status/583279982186786817> 'it is entirely unnecessary to understand category theory in order to understand monads in #haskell' said the guys who know category theory - justusadam_: <https://twitter.com/justusadam_/status/586939066748379136> I'm warming up to the idea of using #Haskell more. Wonderful language but the syntax and some of the concepts were difficult to understand - least_nathan: <https://twitter.com/least_nathan/status/581544451597709312> Algebraic Data Types Considered Harmful: once you use them, every language lacking them drives you to madness. #LangSec - chwthewke: <https://twitter.com/chwthewke/status/583385239138996224> #Haskell is a very hot programming language :) No, really, an hour of it and my laptop is on the verge of becoming a brown dwarf :D - robinbateboerop: <https://twitter.com/robinbateboerop/status/583396694047481857> Troll tries to get banned from #Haskell IRC channel, decides to learn Haskell <http://buff.ly/1NFKWiX> instead. - stephan_gfx: <https://twitter.com/stephan_gfx/status/583493468162400256> Cool, cabal will multithread installation/build if you run it with the -j option. cabal install -j <package_name> - Pythux: <https://twitter.com/Pythux/status/583535948408958976> One thing I learned at Haskell's meetup yesterday: it's possible to create a start-up with Haskell full stack! #Haskell #Awesome *Quote of the week:* - Lisp, Haskell and other FP are currently killing it in the quiet world of DSLs, especially Mining, Oil & Gas industries which need to parse petaflops of seismic data and reservoir simulations, need rapid prototyping, need formally verified drilling platform components that field engineers can interact with easily, and HPC algorithms for financial trading. -- Source <https://news.ycombinator.com/item?id=9317567#up_9318837> -- Kim-Ee

1 0

ANNOUNCE: fast-tags 1.0
by Evan Laforge 13 Apr '15

13 Apr '15

fast-tags makes vi (and now emacs) tags from haskell source. It does so quickly and incrementally. I have it bound to vim's BufWrite to keep tags always updated, and it's basically instant. It works with hsc, literate haskell, and mid-edit files with syntax errors. I've announced this before, but I'm doing it again because it's been a long time and there was a major update. I bumped to 1.0 to reflect that it's not dead, it just does everything I need it to do, so further development is unlikely unless someone finds a bug. That's just for me of course, if someone else wants to add features they are welcome to do so. The major update was almost entirely thanks to Sergey Vinokurov and a few others who contributed a bunch of patches. Details and changelog are at http://hackage.haskell.org/package/fast-tags-1.0 Source is at https://github.com/elaforge/fast-tags

1 0

[Announcement] FLTKHS - Bindings to the FLTK GUI Toolkit
by aditya siram 13 Apr '15

13 Apr '15

I'm pleased to announce the first release of Haskell bindings [1] to the FLTK GUI [2] toolkit. It now works smoothly on Windows (64-bit), Linux and Mac allowing you to create truly cross-platform native GUI applications in pure Haskell and deploy statically linked executables with no dependencies. Most of the FLTK API is covered except for a few minor widgets which I plan to get to in the next release. Motivation behind the package and installation instructions are found in the Haddocks [3]. And to get you started it ships with a number of demos. If you have any issues please report them on the Github [4] page. I'd also love any other feedback so feel free to comment here or email me at the address listed on the Hackage [5] page. Hope you enjoy! [1] https://hackage.haskell.org/package/fltkhs-0.1.0.2 [2] http://fltk.org [3] https://hackage.haskell.org/package/fltkhs-0.1.0.2/docs/Graphics-UI-FLTK-Lo… [4] http://github.com/deech/fltkhs [5] https://hackage.haskell.org/package/fltkhs-0.1.0.2

2 2

Static executables in minimal Docker containers
by Michael Snoyman 13 Apr '15

13 Apr '15

I'm trying to put together a minimal Docker container consisting of nothing but GHC-compiled static executables. Below you can see a full interaction I've had with GHC and Docker. The high level summary is that: * When compiled statically, the executable runs just fine in both my host OS (Ubuntu 14.04) and an Ubuntu 14.04 Docker image * That same executable run from a busybox (or a "scratch" image, not shown here since it's slightly longer to set up) hangs and then runs out of memory I've watched the process in top, and it uses up a huge amount of CPU and memory. I get the same behavior whether I compiled with or without optimizations or the multithreaded runtime. I also get identical behavior with both GHC 7.8.4 and 7.10.1. I'm not sure how best to proceed with trying to debug this, any suggestions? vagrant@vagrant-ubuntu-trusty-64:~/Desktop$ cat > hello.hs <<EOF main :: IO () main = putStrLn "Static Hello" EOF vagrant@vagrant-ubuntu-trusty-64:~/Desktop$ ghc -optl-static -optl-pthread hello.hs -static [1 of 1] Compiling Main ( hello.hs, hello.o ) Linking hello ... /opt/ghc/7.8.4/lib/ghc-7.8.4/rts-1.0/libHSrts.a(Linker.o): In function `internal_dlopen': (.text+0x5c): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking vagrant@vagrant-ubuntu-trusty-64:~/Desktop$ ./hello Static Hello vagrant@vagrant-ubuntu-trusty-64:~/Desktop$ docker run --rm -v $(pwd)/hello:/usr/local/bin/hello:ro ubuntu:14.04 /usr/local/bin/hello Static Hello vagrant@vagrant-ubuntu-trusty-64:~/Desktop$ docker run --rm -v $(pwd)/hello:/usr/local/bin/hello:ro busybox /usr/local/bin/hello hello: out of memory (requested 1048576 bytes) vagrant@vagrant-ubuntu-trusty-64:~/Desktop$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.4

2 2

Re: [Haskell-cafe] Generalized Newtype Deriving not allowed in Safe Haskell
by Simon Peyton Jones 13 Apr '15

13 Apr '15

David If you would like to lead a debate, and drive it to a conclusion, that would be most helpful. Usually it's constructive to write a wiki page that sets out the design choices, with examples to illustrate their consequences, to set the terms of the debate. Otherwise you risk misunderstandings, with red herrings being discussed repeatedly. Thanks Simon | -----Original Message----- | From: davidterei(a)gmail.com [mailto:davidterei@gmail.com] On Behalf Of | David Terei | Sent: 12 April 2015 09:52 | To: Simon Peyton Jones | Cc: Omari Norman; ghc-devs(a)haskell.org; haskell Cafe | Subject: Re: Generalized Newtype Deriving not allowed in Safe Haskell | | On 10 April 2015 at 01:48, Simon Peyton Jones <simonpj(a)microsoft.com> | wrote: | > | prefer, such as only exporting the Coerce instance if all the | > | constructors are exported, it seems that the ship sailed on these | > | > Coercible is relatively recent; I don't think we should regard it as | cast in stone. | > | > But yes, the Coerbible instance of a newtype is only available when | the data constructor for the newtype is lexically in scope. | | Yes, so as you point out in the paper, this is done to preserve | abstractions, but the same rule isn't applied to data types since some | types like IORef don't even have constructors that can be in scope. | | Ideally I'd like to find a way forward that works for everyone and | isn't just a Safe Haskell mode setting. | | I think the first question is, are there situations where you'd want to | use `coerce` internally to a module but disallow it externally? The | role mechanism is a little awkward as it doesn't allow this (although | it does for newtype's). If yes, then I think we should start there. | | If it seems we don't need external vs internal control, then we could | simply change the default to be that GHC sets referential type | parameters to nominal and allows them to be weakened to referential | through role annotations. We could use hackage to test how much | breakage this would cause. | | The third option is something Safe Haskell specific, so probably | applying the newtype constructor rule to data types. | | > | > Simon | > | > | -----Original Message----- | > | From: davidterei(a)gmail.com [mailto:davidterei@gmail.com] On Behalf | > | Of David Terei | > | Sent: 10 April 2015 09:38 | > | To: Simon Peyton Jones | > | Cc: Omari Norman; haskell Cafe; ghc-devs(a)haskell.org | > | Subject: Re: Generalized Newtype Deriving not allowed in Safe | > | Haskell | > | | > | I'll prepare a patch for the userguide soon. | > | | > | As for something better, yes I think we can and should. It's on my | > | todo list :) Basically, the new-GND design has all the mechanisms | > | to be safe, but sadly the defaults are rather worrying. Without | > | explicit annotations from the user, module abstractions are | broken. | > | This is why we left GND out of Safe Haskell for the moment as it | is | > | a subtle and easy mistake to make. | > | | > | If the module contained explicit role annotations then it could be | > | allowed. The discussion in | > | https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions | > | that I prefer, such as only exporting the Coerce instance if all | > | the constructors are exported, it seems that the ship sailed on | > | these bigger changes sadly. | > | | > | Cheers, | > | David | > | | > | On 9 April 2015 at 00:56, Simon Peyton Jones | > | <simonpj(a)microsoft.com> | > | wrote: | > | > There is a long discussion on | > | > https://ghc.haskell.org/trac/ghc/ticket/8827 | > | > about whether the new Coercible story makes GND ok for Safe | Haskell. | > | > At a type-soundness level, definitely yes. But there are other | > | > less-clear-cut issues like “breaking abstractions” to consider. | > | The > decision on the ticket > (comment:36) seems to be: GND | stays | > | out of Safe Haskell for now, but > there is room for a better | > | proposal. | > | > | > | > | > | > | > | > I don’t have an opinion myself. David Terei and David Mazieres | > | are in > the driving seat, but I’m sure they’ll be responsive to | user input. | > | > | > | > | > | > | > | > However, I think the user manual may not have kept up with | #8827. | > | The | > | > sentence “GeneralizedNewtypeDeriving — It can be used to violate | > | > constructor access control, by allowing untrusted code to | > | manipulate > protected data types in ways the data type author did | > | not intend, > breaking invariants they have established.” | vanished | > | from the 7.8 > user manual (links below). Maybe it should be | restored. | > | > | > | > | > | > | > | > Safe Haskell aficionados, would you like to offer a patch for | the | > | manual? | > | > And maybe also a less drastic remedy than omitting GND | altogether? | > | > | > | > | > | > | > | > Simon | > | > | > | > | > | > | > | > From: Omari Norman [mailto:omari@smileystation.com] > Sent: 09 | > | April 2015 02:44 > To: haskell Cafe > Subject: Generalized | Newtype | > | Deriving not allowed in Safe Haskell > > > > When compiling | code | > | with Generalized Newtype Deriving and the > -fwarn-unsafe flag, I | > | get > > > > -XGeneralizedNewtypeDeriving is not allowed in Safe | > | Haskell > > > > This happens both in GHC 7.8 and GHC 7.10. | > | > | > | > | > | > | > | > I thought I remembered reading somewhere that GNTD is now part | of | > | the > safe language? The GHC manual used to state that GNTD is | not | > | allowed > in Safe > Haskell: | > | > | > | > | > | > | > | > | > | | https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe- | > | ha | > | > skell.html#safe-language | > | > | > | > | > | > | > | > But this language on GNTD not being part of the safe language | was | > | > removed in the 7.8 manual: | > | > | > | > | > | > | > | > | > | | https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe- | > | ha | > | > skell.html#safe-language | > | > | > | > | > | > | > | > The GHC release notes don't say anything about this one way or | > | the other. | > | > Thoughts? | > | > | > | > | > | > _______________________________________________ | > | > ghc-devs mailing list | > | > ghc-devs(a)haskell.org | > | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs(a)haskell.org | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

Dealing with GHC 7.10 prelude imports
by Brendan Hay 13 Apr '15

13 Apr '15

Hi, I've run into a couple of cases when attempting to support multiple GHC versions in my libraries (7.6.3 -> 7.10) where I've repeatedly made mistakes due to being warned about unused imports for various modules that are now part of the Prelude such as Data.Monoid, Data.Foldable, etc. which I subsequently remove either manually or via editor automation sufficiently indistinguishable from magic. This then results in successful compilation on 7.10 and failure on earlier versions of GHC due to missing imports (ie. Data.Monoid (mappend, mempty)), which prior to my current workflow of manually building on multiple versions of GHC before releasing a new version, manifested once or twice only after uploading to Hackage. Now this is all user/workflow error on my part, but I wondered if others have some kind of trick up their sleeve for avoiding these kind of issues? I could attempt to tailor the compiler's warning flags appropriately, but it bodes ill for spotting genuinely unused imports. Cheers, Brendan

5 5

Re: [Haskell-cafe] Generalized Newtype Deriving not allowed in Safe Haskell
by Richard Eisenberg 12 Apr '15

12 Apr '15

On Apr 12, 2015, at 9:51 AM, David Terei <dave.terei(a)gmail.com> wrote: > > Ideally I'd like to find a way forward that works for everyone and > isn't just a Safe Haskell mode setting. Agreed. I'm not convinced this can be done, but it's certainly worth trying. > > I think the first question is, are there situations where you'd want > to use `coerce` internally to a module but disallow it externally? The > role mechanism is a little awkward as it doesn't allow this (although > it does for newtype's). If yes, then I think we should start there. Yes, the ability to use `coerce` within one module but not elsewhere would be nice. This can currently be simulated (without too much difficulty) with newtypes. A datatype D can have a more permissive role signature than an equivalent newtype N (where `newtype N = MkN D`). The package then exports N (without its constructor). This effectively allows local uses of `coerce`, even for datatypes. A more direct mechanism would be better, but I don't think we should bend over backwards for it. > > If it seems we don't need external vs internal control, then we could > simply change the default to be that GHC sets referential type > parameters to nominal and allows them to be weakened to referential > through role annotations. We could use hackage to test how much > breakage this would cause. I worry that the breakage would be significant. But, now that authors have had a chance to put in role annotations, maybe it wouldn't be so bad. The change to GHC to make this happen is trivial: just change default_role in TcTyDecls.initialRoleEnv1. I don't have the infrastructure around to make an all-of-Hackage test, but I'm happy to support someone else who does. Richard

1 0

Re: [Haskell-cafe] Generalized Newtype Deriving not allowed in Safe Haskell
by Richard Eisenberg 10 Apr '15

10 Apr '15

Here's an idea: For a module to be Safe, then for each exported datatype, one of the following must hold: 1) The datatype comes with a role annotation. 2) The module exports all of the datatype's constructors. 3) If the datatype is defined in a place other than the current module, the current module exports no fewer data constructors than are exported in the datatype's defining module. Why? 1) The role annotation, even if it has no effect, shows that the programmer has considered roles. Any mistake here is clearly the programmer's fault. 2) This datatype is clearly meant not to be abstract. `Coercible` then gives clients no more power than they already have. 3) This is subtler. It is a common idiom to export a datatype's constructors from a package-internal module, but then never to export the constructors beyond the package. If such a datatype has a role annotation (in its defining module, of course), then we're fine, even if it is exported abstractly later. However, suppose we are abstractly re-exporting a datatype that exports its constructors from its defining module. If there is no role annotation on the datatype, we're in trouble and should fail. BUT, if the datatype were exported abstractly in its defining module, then we don't need to fail on re-export, because nothing has changed. Actually, we could simplify the conditions. Change (2) to: 2') The module exports all of the datatype's visible constructors. I think explaining in terms of separate rules (2) and (3) is a little clearer, because the re-export case is slightly subtle, and this subtlety can be lost in (2'). This proposal would require tracking (in interface files, too) whether or not a datatype comes with a role annotation. This isn't hard, though. It might even help in pretty-printing. An alternative would be to have a way of setting roles differently on export than internally. I don't think this breaks the type system, but it's yet another thing to specify and support. And we'd have to consider the possibility that some module will import a datatype from multiple re-exporting modules, each with different ascribed role annotations. Is this an error? Does GHC take some sort of least upper bound? I prefer not to go here, but there's nothing terribly wrong with this approach. Richard On Apr 10, 2015, at 9:37 AM, David Terei <dave.terei(a)gmail.com> wrote: > I'll prepare a patch for the userguide soon. > > As for something better, yes I think we can and should. It's on my > todo list :) Basically, the new-GND design has all the mechanisms to > be safe, but sadly the defaults are rather worrying. Without explicit > annotations from the user, module abstractions are broken. This is why > we left GND out of Safe Haskell for the moment as it is a subtle and > easy mistake to make. > > If the module contained explicit role annotations then it could be > allowed. The discussion in > https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions that > I prefer, such as only exporting the Coerce instance if all the > constructors are exported, it seems that the ship sailed on these > bigger changes sadly. > > Cheers, > David > > On 9 April 2015 at 00:56, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: >> There is a long discussion on https://ghc.haskell.org/trac/ghc/ticket/8827 >> about whether the new Coercible story makes GND ok for Safe Haskell. At a >> type-soundness level, definitely yes. But there are other less-clear-cut >> issues like “breaking abstractions” to consider. The decision on the ticket >> (comment:36) seems to be: GND stays out of Safe Haskell for now, but there >> is room for a better proposal. >> >> >> >> I don’t have an opinion myself. David Terei and David Mazieres are in the >> driving seat, but I’m sure they’ll be responsive to user input. >> >> >> >> However, I think the user manual may not have kept up with #8827. The >> sentence “GeneralizedNewtypeDeriving — It can be used to violate constructor >> access control, by allowing untrusted code to manipulate protected data >> types in ways the data type author did not intend, breaking invariants they >> have established.” vanished from the 7.8 user manual (links below). Maybe >> it should be restored. >> >> >> >> Safe Haskell aficionados, would you like to offer a patch for the manual? >> And maybe also a less drastic remedy than omitting GND altogether? >> >> >> >> Simon >> >> >> >> From: Omari Norman [mailto:omari@smileystation.com] >> Sent: 09 April 2015 02:44 >> To: haskell Cafe >> Subject: Generalized Newtype Deriving not allowed in Safe Haskell >> >> >> >> When compiling code with Generalized Newtype Deriving and the -fwarn-unsafe >> flag, I get >> >> >> >> -XGeneralizedNewtypeDeriving is not allowed in Safe Haskell >> >> >> >> This happens both in GHC 7.8 and GHC 7.10. >> >> >> >> I thought I remembered reading somewhere that GNTD is now part of the safe >> language? The GHC manual used to state that GNTD is not allowed in Safe >> Haskell: >> >> >> >> https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe-haskell… >> >> >> >> But this language on GNTD not being part of the safe language was removed in >> the 7.8 manual: >> >> >> >> https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe-haskell… >> >> >> >> The GHC release notes don't say anything about this one way or the other. >> Thoughts? >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >

3 2

indexed writer monad
by Nicholls, Mark 10 Apr '15

10 Apr '15

Anyone? I can handle monads, but I have something (actually in F#) that feels like it should be something like a indexed writer monad (which F# probably wouldn't support). So I thought I'd do some research in Haskell. I know little or nothing about indexed monad (though I have built the indexed state monad in C#). So I would assume there would be an indexed monoid (that looks at bit like a tuple?)... e.g. (a,b) ++ (c,d) = (a,b,c,d) (a,b,c,d) ++ (e) = (a,b,c,d,e) ? There seems to be some stuff about "update monads", but it doesn't really look like a writer. I could do with playing around with an indexed writer, in order to get my head around what I'm doing....then try and capture what I'm doing...then try (and fail) to port it back. CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT.

3 12

Haskell on BBC Radio 4
by Colin Adams 10 Apr '15

10 Apr '15

Haskell featured strongly today in the last Episode of Radio 4's "Codes that changed the world": http://www.bbc.co.uk/programmes/b05prkh7

2 1

Re: [Haskell-cafe] PrimMonad for Control.Monad.ST.Lazy?
by oleg＠okmij.org 10 Apr '15

10 Apr '15

Ken Takusagawa II wrote: > What I Am Really Trying To Do: get a purely lazy stream of random values Streams of random data is actually somewhat popular structure, and has been asked about before. What was also found out that such lazy streams are fraught with problems. Some are described on this page: http://okmij.org/ftp/continuations/PPYield/index.html#randoms The page also shows two solutions, which are robust and easy to reason about. Lazy evaluation does promote compositionality on one hand, and it also inhibits compositionality. Reasoning about lazy programs is inherently non-compositional, breaking abstraction boundaries, as the page demonstrates. Overall, lazy evaluation has not worked out as it was originally hoped for. There are alternatives that are more compositional and easier to reason about, including reasoning about performance.

4 4

Re: [Haskell-cafe] Generalized Newtype Deriving not allowed in Safe Haskell
by Simon Peyton Jones 10 Apr '15

10 Apr '15

| prefer, such as only exporting the Coerce instance if all the | constructors are exported, it seems that the ship sailed on these Coercible is relatively recent; I don't think we should regard it as cast in stone. But yes, the Coerbible instance of a newtype is only available when the data constructor for the newtype is lexically in scope. Simon | -----Original Message----- | From: davidterei(a)gmail.com [mailto:davidterei@gmail.com] On Behalf Of | David Terei | Sent: 10 April 2015 09:38 | To: Simon Peyton Jones | Cc: Omari Norman; haskell Cafe; ghc-devs(a)haskell.org | Subject: Re: Generalized Newtype Deriving not allowed in Safe Haskell | | I'll prepare a patch for the userguide soon. | | As for something better, yes I think we can and should. It's on my todo | list :) Basically, the new-GND design has all the mechanisms to be | safe, but sadly the defaults are rather worrying. Without explicit | annotations from the user, module abstractions are broken. This is why | we left GND out of Safe Haskell for the moment as it is a subtle and | easy mistake to make. | | If the module contained explicit role annotations then it could be | allowed. The discussion in | https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions that I | prefer, such as only exporting the Coerce instance if all the | constructors are exported, it seems that the ship sailed on these | bigger changes sadly. | | Cheers, | David | | On 9 April 2015 at 00:56, Simon Peyton Jones <simonpj(a)microsoft.com> | wrote: | > There is a long discussion on | > https://ghc.haskell.org/trac/ghc/ticket/8827 | > about whether the new Coercible story makes GND ok for Safe Haskell. | > At a type-soundness level, definitely yes. But there are other | > less-clear-cut issues like “breaking abstractions” to consider. The | > decision on the ticket | > (comment:36) seems to be: GND stays out of Safe Haskell for now, but | > there is room for a better proposal. | > | > | > | > I don’t have an opinion myself. David Terei and David Mazieres are in | > the driving seat, but I’m sure they’ll be responsive to user input. | > | > | > | > However, I think the user manual may not have kept up with #8827. | The | > sentence “GeneralizedNewtypeDeriving — It can be used to violate | > constructor access control, by allowing untrusted code to manipulate | > protected data types in ways the data type author did not intend, | > breaking invariants they have established.” vanished from the 7.8 | > user manual (links below). Maybe it should be restored. | > | > | > | > Safe Haskell aficionados, would you like to offer a patch for the | manual? | > And maybe also a less drastic remedy than omitting GND altogether? | > | > | > | > Simon | > | > | > | > From: Omari Norman [mailto:omari@smileystation.com] | > Sent: 09 April 2015 02:44 | > To: haskell Cafe | > Subject: Generalized Newtype Deriving not allowed in Safe Haskell | > | > | > | > When compiling code with Generalized Newtype Deriving and the | > -fwarn-unsafe flag, I get | > | > | > | > -XGeneralizedNewtypeDeriving is not allowed in Safe Haskell | > | > | > | > This happens both in GHC 7.8 and GHC 7.10. | > | > | > | > I thought I remembered reading somewhere that GNTD is now part of the | > safe language? The GHC manual used to state that GNTD is not allowed | > in Safe | > Haskell: | > | > | > | > https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe- | ha | > skell.html#safe-language | > | > | > | > But this language on GNTD not being part of the safe language was | > removed in the 7.8 manual: | > | > | > | > https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe- | ha | > skell.html#safe-language | > | > | > | > The GHC release notes don't say anything about this one way or the | other. | > Thoughts? | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs(a)haskell.org | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | >

1 0

ANN: exact-pi 0.1
by Douglas McClean 10 Apr '15

10 Apr '15

I'm announcing the release of the new exact-pi package. It provides a type that exactly represents all rational multiples of integer powers of pi. Because it's closed under multiplication and taking of reciprocals, it's useful for computing exact conversion factors between physical units. In order to provide full Num and Floating instances there is also a representation for approximate values. I'm not sure if this will be of use to anyone else, but it is nice and self-contained so I thought I would put it out there. -Doug McClean

3 3

PrimMonad for Control.Monad.ST.Lazy?
by Ken Takusagawa II 10 Apr '15

10 Apr '15

I notice that the strict ST monad has an instance for PrimMonad but the lazy ST monad does not. Is there a reason why, or is merely an oversight? (What I Am Really Trying To Do: get a purely lazy stream of random values out of mwc-random.) --ken

3 2

Cabal hell
by Patrick Redmond 09 Apr '15

09 Apr '15

Since learning Haskell I've had the pleasure of finding my way out of a cabal hell or two. I've developed some knowledge to cope with it [1], but mostly concluded that if I can avoid burdening my projects with dependencies that have many of their own dependencies, then cabal hell can be averted. This puts somewhat of a damper on the joy of haskell's composability. With the new release of GHC I've observed a flurry of discussion on haskell mailing lists and from Linux distro maintainers about all the fixing and patching required to keep the haskell ecosystem going. Meanwhile I've learned other languages and used other tools that don't seem to have this problem that haskell does. For example, in the elm-lang community the package management tool enforces strict api-versioning, and in the clojure ecosystem people talk about "repeatability" and achieve it by using mostly exact-version requirements, even including the language (the language version is a dependency of a project, rather than a constraint of the environment). I guess I'm wondering why we don't try something simpler to solve the haskell cabal hell problem. How about using minimum version dependencies only, not ranges, since we can't accurately guess about the future compatibility of our projects. How about automatic api-versioning of our projects to give the version numbers some rigid semantics with regard to package compatibility? [1] http://f06code.com/post/90205977959/cabal-usage-notes

3 5

help w/ improving custom Stream for parsec
by Maurizio Vitale 09 Apr '15

09 Apr '15

I need a custom stream that supports insertion of include files and expansions of macros. I also want to be able to give nice error messages (think of clang macro-expansion backtrace), so I cannot use the standard trick of concatenating included files and expanded macros to the current input with setInput/getInput (I think I can't maybe there's a way of keeping a more complex "position" and since the use in producing an error backtrac is rare, it migth be worth exploring; if anybody has ideas here, I'm listening) Assuming I need a more compelx stream, this is what I have (Macro and File both have a string argument, but it will be more compicated, a list of expansions for Macro for instance). Is there a better way for doing this? What are the performance implications with backtracking? I'll be benchmarking it, but if people see obvious problems, let me know. Thanks a lot, Maurizio {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE MultiParamTypeClasses #-} module Parsing where import Text.Parsec type Parser s m = ParsecT s () m data VStream = File String | Macro String deriving Show newtype StreamStack = StreamStack [VStream] deriving Show instance (Monad m) ⇒ Stream VStream m Char where uncons ∷ VStream -> m (Maybe (Char, VStream)) uncons (File (a:as)) = return $ Just (a, File as) uncons (File []) = return Nothing uncons (Macro (a:as)) = return $ Just (a, File as) uncons (Macro []) = return Nothing instance (Monad m) => Stream StreamStack m Char where uncons (StreamStack []) = return Nothing uncons (StreamStack (s:ss)) = case uncons s of Nothing → uncons $ StreamStack ss Just Nothing → uncons $ StreamStack ss Just (Just (c, File s')) → return $ Just (c, StreamStack (File s': ss)) Just (Just (c, Macro s')) → return $ Just (c, StreamStack (Macro s':ss))

2 5

VACANCIES : 3x PhD position in Fuctional Programming
by Johan Jeuring 09 Apr '15

09 Apr '15

The research group of Software Technology is part of the Software Systems division of in the department of Information and Computer Science at the Utrecht University. We focus our research on functional programming, compiler construction, tools for learning and teaching (serious games, intelligent tutoring systems), program analysis, validation, and verification. Financed by the Technology Foundation STW, the EU, and Utrecht University we currently have job openings for: ** 3x PhD researcher (PhD student) in Functional Programming ** We are looking for PhD students to develop functional programming techniques related to parsing, rewriting, property-based testing, dependently typed programming, or program analysis, and to apply these techniques in several applications, such as distributed systems, applied games, dialogue management systems, or assessment tools. Besides research, the successful candidate will be expected to help supervise MSc students and assist courses. We prefer candidates to start no later than September 2015. --------------------------------- What we are looking for --------------------------------- The candidate should have an MSc in Computer Science with good grades, be highly motivated to pursue a PhD, and speak and write English well. Knowledge of functional programming, such as Haskell or ML is essential. --------------------------------- What we offer --------------------------------- The candidate is offered a full-time salaried position for four years. The salary is supplemented with a holiday bonus of 8% and an end-of-year bonus of 8,3% per year. In addition we offer: a pension scheme, partially paid parental leave, flexible employment conditions. Conditions are based on the Collective Labour Agreement Dutch Universities. The research group will provide the candidate with necessary support on all aspects of the project. More information is available on the website: Terms and employment: http://bit.ly/1elqpM7 Salary starts at € 2,083.- and increases to € 2,664.- gross per month in the fourth year of the appointment. Utrecht is a great place to live, having been ranked as one of the happiest places in the world, according to BBC travel. Living in Utrecht: http://bitly.com/HdbL0X --------------------------------- In order to apply --------------------------------- To apply please attach a letter of motivation, a curriculum vitae, and (email) addresses of two referees. Make sure to also include a transcript of the courses you have followed (at bachelor and master level), with the grades you obtained, and to include a sample of your scientific writing, such as your master thesis. It is possible to apply for this position if you are close to obtaining your Master's. In that case include a letter of your supervisor with an estimate of your progress, and do not forget to include at least a sample of your technical writing skills. Applications are accepted until the positions are filled. Send your application via email to Johan Jeuring: J.T.Jeuring(a)uu.nl --------------- Contact person --------------- For further information you can direct your inquiries to: Johan Jeuring phone: +31 (0)30 253 4115/ (0) 6 40010053 e-mail: J.T.Jeuring(a)uu.nl website: http://www.staff.science.uu.nl/~jeuri101/

1 0