- Haskell-Cafe - Haskell.org

ANN: Yampa 0.9.7 and 0.10.0
by Ivan Perez 06 May '15

06 May '15

Dear all Two new versions of Yampa have just been made available on hackage. A short reminder for those who don't know: Yampa is a Functional Reactive Programming DSL structured around Signal Functions. It enforces a separation between effectful input/output and purely functional signal transformations. Arrow notation can be used to connect signal functions. Yampa has recently been used to write several games available on Github [2] and Google Play (for Android) [3, 4]. Regarding the new versions: - Version 0.9.7 is fully backwards compatible and includes minimal changes. - Version 0.10.0 is mostly, but not fully, backwards compatible and has been restructured in modules to make documentation easier. We expect this to help users find and understand the available combinators better. I have tried both versions with the game Haskanoid [2] and they work. If your project cannot be compiled or executed correctly with either version, please open an issue on our project page [1]. Yampa is being actively developed, and we are working on FRP extensions that we hope will be introduced in future versions. Code, documentation and research contributions are welcome. All the best Ivan [1] https://github.com/ivanperez-keera/Yampa [2] https://github.com/ivanperez-keera/haskanoid [3] https://play.google.com/store/apps/details?id=uk.co.keera.games.magiccookies [4] https://github.com/keera-studios/magic-cookies

1 1

Re: [Haskell-cafe] Significant changes in -Wall for GHC 7.10
by Alexander Eyers-Taylor 06 May '15

06 May '15

Sorry I forgot to reply to the list. Here is my earlier email -------- Forwarded Message -------- Subject: Re: [Haskell-cafe] Significant changes in -Wall for GHC 7.10 Date: Tue, 05 May 2015 16:29:46 +0100 From: Alexander Eyers-Taylor <aeyerstaylor11(a)gmail.com> To: Omari Norman <omari(a)smileystation.com> Those seem to be preciously the flags enabled by -Wall. It seems when updating the documentation the negative was missed and it was updated to list the flags enabled by -Wall. I have submitted a ticket (#10386) to fix the bug. On 05/05/15 16:03, Omari Norman wrote: > CORRECTION: -fwarn-trustworthy-safe was not in -Wall in GHC 7.8, but > -fwarn-trustworthy-safe did not exist in GHC 7.8. > > On Tue, May 5, 2015 at 10:54 AM, Omari Norman <omari(a)smileystation.com > <mailto:omari@smileystation.com>> wrote: > > I noticed some significant changes to the flags included with > -Wall in GHC 7.10. Many flags that were previously included in > -Wall are now not included. These include: > > -fwarn-type-defaults > -fwarn-name-shadowing > -fwarn-missing-signatures > -fwarn-hi-shadowing > -fwarn-orphans > -fwarn-unused-do-bind > -fwarn-trustworthy-safe > > I can't find any mention in the release notes of this change in > behavior. > > I was wondering what the rationale is for these changes? Any link > to relevant discussion would be appreciated if it exists. > > Also, what opinion do people have? I previously kept my code > -Wall clean, but sometimes that would be a pain. For instance I > would munge local names so they wouldn't trigger > -fwarn-name-shadowing, and I would add signatures to integers so > they wouldn't trigger -fwarn-type-defaults. In fact, I only > noticed this change in behavior in 7.10 because I was considering > dumping -Wall, and when I looked at the 7.10 manual I saw that it > does not enable -fwarn-name-shadowing. (I still use 7.8 but > Google pulled the 7.10 manual.) Does this change indicate that > people were finding -Wall too onerous and, thus, not using it? > > I do remember reading complaints about -fwarn-unused-do-bind being > added to -Wall, but I previously felt dirty about name shadowing > though I wondered if munging names to avoid shadowing was actually > worse. > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

1 0

Significant changes in -Wall for GHC 7.10
by Omari Norman 06 May '15

06 May '15

I noticed some significant changes to the flags included with -Wall in GHC 7.10. Many flags that were previously included in -Wall are now not included. These include: -fwarn-type-defaults -fwarn-name-shadowing -fwarn-missing-signatures -fwarn-hi-shadowing -fwarn-orphans -fwarn-unused-do-bind -fwarn-trustworthy-safe I can't find any mention in the release notes of this change in behavior. I was wondering what the rationale is for these changes? Any link to relevant discussion would be appreciated if it exists. Also, what opinion do people have? I previously kept my code -Wall clean, but sometimes that would be a pain. For instance I would munge local names so they wouldn't trigger -fwarn-name-shadowing, and I would add signatures to integers so they wouldn't trigger -fwarn-type-defaults. In fact, I only noticed this change in behavior in 7.10 because I was considering dumping -Wall, and when I looked at the 7.10 manual I saw that it does not enable -fwarn-name-shadowing. (I still use 7.8 but Google pulled the 7.10 manual.) Does this change indicate that people were finding -Wall too onerous and, thus, not using it? I do remember reading complaints about -fwarn-unused-do-bind being added to -Wall, but I previously felt dirty about name shadowing though I wondered if munging names to avoid shadowing was actually worse.

2 4

finding things on haskell.org
by Doug McIlroy 05 May '15

05 May '15

The only search feature I'm aware of on the haskell website is the haskell wiki, which is a self-contained little corner. For example, the wiki says nothing about minGHC. To find out what the website has on the subject, I used a Google query: site:haskell.org minghc. Is there thought of a comprehensive site-search facility that can find anything, including stuff that hasn't been wiki-ized? Doug

2 1

Language.Perl? (static analysis of Perl code, in Haskell)
by Johannes Waldmann 05 May '15

05 May '15

I am investigating options for analyzing, and refactoring, legacy Perl code. Ideally, the tools would be in a high-level language like Haskell. I found [Pugs][1] and (related) [Language.Perl5][2] but both appear dead. Is there something for Perl that would provide what [hack][4] provides for PHP, and [typescript][5] for JS? (Perhaps I should write a Perl to PHP compiler.) Yes, I know that [Perl is not parseable][3]. - J.W. [1]: http://hackage.haskell.org/package/Pugs [2]: http://hackage.haskell.org/package/HsPerl5 [3]: http://www.perlmonks.org/?node_id=800599 [4]: http://hacklang.org/ [5]: http://www.typescriptlang.org/

1 0

Re: [Haskell-cafe] Improvements to package hosting and security
by Mathieu Boespflug 05 May '15

05 May '15

This is a valid concern. One that I should have addressed explicitly in the proposal. Git is fairly well supported on Windows these days and installs easily. It could conceivably be included as part of MinGHC. There are many alternatives, but I doubt we'll need them: statically linking a C implementation (libgit2 or another), or a simple native implementation of the git protocol (the protocol is quite straightforward and is documented) and basic disk format. The same is true about GnuPG, via gpg4win, though note that under this proposal GnuPG wouldn't be a requirement for `cabal update` to work. Just an additional optional dependency which you'll want to have installed if you want to protect yourself from the attacks listed in the proposal. By the way, one side note about this Git proposal: it sides steps the discussion around how to add SSL support to cabal-install entirely. Since Git understands (among others) HTTPS natively, so we can outsource our support for that to Git. In any case SSL no longer becomes a necessity for protecting against MITM (the commit signing takes care of that), only a nice-to-have for privacy. On 28 April 2015 at 19:46, <radix(a)twistedmatrix.com> wrote: > To me, the elephant in the room is how the dependency on Git will be > handled. I'm not a Windows user, but how much more painful will it be to set > up a Haskell environment on Windows with a new dependency on Git? Will users > need to install it separately, or do you suggest embedding Git into the > relevant tools? Should the Haskell Platform bundle it? What about MinGHC? > Oh, and I guess the same question can be asked about GnuPG. > > I personally use a Mac and Homebrew, so it's pretty easy for me to install > those dependencies, and I'm sure the same is true on Linux. But also, not > everyone uses Homebrew (in fact, I'm sure most programmers on Macs don't use > it), so it's also worth considering whether the requisite tools should be > embedded in the "GHC for Mac OS X" distribution. > > On Linux this probably isn't an issue because pretty much everyone has a > decent dependency-tracking package manager. > > I don't know if you care personally about these issues, but I think any > proposal which introduces new dependencies to the core development > environment of Haskell should take it into consideration. Very few people > have Git and GPG already installed, and I think the new-user experience > should be considered, and I'm surprised nobody has mentioned it in this > entire thread (unless I missed it). > > -- radix (Christopher Armstrong) > > P.S. I'm very excited to see this work, including the emphasis on using the > well-researched TUF. Thanks to you and other people working on this. :) > > On Tuesday, April 28, 2015 at 5:07:56 AM UTC-5, Mathieu Boespflug wrote: >> >> Hi all, >> >> last week, I found some time to write up a very simple proposal that >> addresses the following goals simultaneously: >> >> - maintain a difficult to forge public audit log of Hackage updates; >> - make downloads from Hackage mirrors just as trustworthy as >> downloading from Hackage itself; >> - guarantee that `cabal update` is always pulling the freshest package >> index (called "snapshots" in the proposal), and detect when this might >> not be the case; >> - implement the first half of TUF (namely the index signing part >> discussed in Duncan's blog post, not the author package signing part) >> with fewer metadata files and in a way that reuses existing tooling; >> - get low-implementation-cost, straightforward and incremental `cabal >> update`. >> >> After a preliminary review from a few colleagues and friends in the >> community, here is the proposal, in the form of Commercial Haskell >> wiki page: >> >> >> https://github.com/commercialhaskell/commercialhaskell/wiki/Git-backed-Hack… >> >> The design constraints here are: >> >> - stay backwards compatible where the cost for doing so is low. >> - reuse existing tooling and mechanisms, especially when it comes to >> key management, snapshot identity, and distributing signatures. >> - Focus on the above 5 goals only, because they happen to all be >> solvable by changing a single piece of mechanism. But strive to reuse >> whatever mechanism others are proposing to solve other goals (e.g. >> certification of provenance using author package signing, as Chris >> Done has already proposed). >> >> To that effect, the tl;dr is that I'm proposing that we just use Git >> for maintaining the Hackage package index, that we use Git for >> synchronizing this locally, and that we use Git commit signatures for >> implementing the first half of TUF. The Git tooling currently assumes >> GnuPG keys for signatures, so I'm proposing that we use GnuPG keys for >> signing, and that we manage key revocation and any trust delegation >> between keys using GnuPG and its existing infrasture. >> >> I estimate the total effort necessary here to be the equivalent of 5-6 >> full time days overall. However, I have not pooled the necessary >> resources to carry that out yet. I'd like to get feedback first before >> going ahead with this, but in meantime, >> >> ** if there are any volunteers that would like to signal their intent >> to help with the implementation effort then please add your name at >> the bottom of the wiki page. ** >> >> Best, >> >> Mathieu >> >> On 18 April 2015 at 20:11, Michael Snoyman <mic...@snoyman.com> wrote: >> > >> > >> > On Sat, Apr 18, 2015 at 12:20 AM Bardur Arantsson >> > <sp...@scientician.net> >> > wrote: >> >> >> >> On 17-04-2015 10:17, Michael Snoyman wrote: >> >> > This is a great idea, thank you both for raising it. I was discussing >> >> > something similar with others in a text chat earlier this morning. >> >> > I've >> >> > gone ahead and put together a page to cover this discussion: >> >> > >> >> > >> >> > >> >> > https://github.com/commercialhaskell/commercialhaskell/blob/master/proposal… >> >> > >> >> > The document definitely needs more work, this is just meant to get >> >> > the >> >> > ball >> >> > rolling. As usual with the commercialhaskell repo, if anyone wants >> >> > edit >> >> > access, just request it on the issue tracker. Or most likely, send a >> >> > PR >> >> > and >> >> > you'll get a commit bit almost magically ;) >> >> >> >> Thank you. Just to make sure that I understand -- is this page only >> >> meant to cover the original "strawman proposal" at the start of this >> >> thread, or...? >> >> >> >> Maybe you intend for this to be extended in a detailed way under the >> >> "Long-term solutions" heading? >> >> >> >> I was imagining a wiki page which could perhaps start out by collecting >> >> all the currently identified possible threats in a table, and then all >> >> "participants" could perhaps fill in how their suggestion addresses >> >> those threats (or tell us why we shouldn't care about this particular >> >> threat). Of course other relevent non-threat considerations might be >> >> relevant to add to such a table, such as: how prevalent is the >> >> software/idea we're basing this on? does this have any prior >> >> implementation (e.g. the append-to-tar and expect that web servers will >> >> behave sanely thing)? etc. >> >> >> >> (I realize that I'm asking for a lot of work, but I think it's going to >> >> be necessary, at least if there's going to be consensus and not just a >> >> de-facto "winner".) >> >> >> >> >> > >> > Hi Bardur, >> > >> > >> > I don't think I have any different intention for this page than you've >> > identified. In fact, I thought that I had clearly said exactly what you >> > described when I said: >> > >> >> There are various ideas at play already. The bullets are not intended >> >> to >> >> be full representations of the proposals, but rather high level >> >> summaries. >> >> We should continue to expand this page with more details going forward. >> > >> > If this is unclear somehow, please tell me. But my intention absolutely >> > is >> > that many people can edit this page to add their ideas and we can flesh >> > out >> > a complete solution. >> > >> > Michael >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskel...@haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskel...@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

7 14

IFL 2015 -- call for papers
by Simon Thompson 05 May '15

05 May '15

IFL 2015 - Call for papers 27th SYMPOSIUM ON IMPLEMENTATION AND APPLICATION OF FUNCTIONAL LANGUAGES - IFL 2015 University of Koblenz-Landau, Koblenz, Germany In cooperation with ACM SIGPLAN September 14-16, 2015 http://ifl2015.wikidot.com/ Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2015 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Peer-review Following the IFL tradition, IFL 2015 will use a post-symposium review process to produce the formal proceedings. All participants of IFL2015 are invited to submit either a draft paper or an extended abstract describing work to be presented at the symposium. At no time may work submitted to IFL be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy: http://www.sigplan.org/Resources/Policies/Republication The submissions will be screened by the program committee chair to make sure they are within the scope of IFL, and will appear in the draft proceedings distributed at the symposium. Submissions appearing in the draft proceedings are not peer-reviewed publications. Hence, publications that appear only in the draft proceedings do not count as publication for the ACM SIGPLAN republication policy. After the symposium, authors will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal review process. From the revised submissions, the program committee will select papers for the formal proceedings considering their correctness, novelty, originality, relevance, significance, and clarity. Important dates August 10: Submission deadline draft papers August 12: Notification of acceptance for presentation August 14: Early registration deadline August 21: Late registration deadline September 7: Submission deadline for pre-symposium proceedings September 14-16: IFL Symposium December 1: Submission deadline for post-symposium proceedings January 15, 2016: Notification of acceptance for post-symposium proceedings March 1, 2016: Camera-ready version for post-symposium proceedings Submission details Prospective authors are encouraged to submit papers or extended abstracts to be published in the draft proceedings and to present them at the symposium. All contributions must be written in English. Papers must adhere to the standard ACM two columns conference format. For the pre-symposium proceedings we adopt a 'weak' page limit of 12 pages. For the post-symposium proceedings the page limit of 12 pages is firm. A suitable document template for LaTeX can be found at: http://www.acm.org/sigs/sigplan/authorInformation.htm Authors submit through EasyChair: https://easychair.org/conferences/?conf=ifl2015 Topics IFL welcomes submissions describing practical and theoretical work as well as submissions describing applications and tools in the context of functional programming. If you are not sure whether your work is appropriate for IFL 2015, please contact the PC chair at rlaemmel(a)acm.org. Topics of interest include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialization - run-time code generation - partial evaluation - (abstract) interpretation - metaprogramming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - (industrial) applications Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. Programme committee Chair: Ralf Lämmel, University of Koblenz-Landau, Germany - Malgorzata Biernacka, University of Wroclaw, Poland - Laura M. Castro, University of A Coruña, Spain - Martin Erwig, Oregon State University, USA - Dan Ghica, University of Birmingham, UK - Andrew Gill, University of Kansas, USA - Stephan Herhut, Google, USA - Zhenjiang Hu, National Institute of Informatics (NII), Japan - Mauro Jaskelioff, CIFASIS/Universidad Nacional de Rosario, Argentina - Frédéric Jouault, ESEO, France - Oleg Kiselyov, Tohoku University, Japan - Lindsey Kuper, Indiana University, USA - Rita Loogen, Philipps-Universität Marburg, Germany - Akimasa Morihata, University of Tokyo, Japan - Atsushi Ohori, Tohoku University, Japan - Bruno C. D. S. Oliveira, The University of Hong Kong, Hong Kong - Frank Piessens, Katholieke Universiteit Leuven, Belgium - Norman Ramsey, Tufts University, USA - Matthew Roberts, Macquarie University, Australia - Manfred Schmidt-Schauss, Goethe-University Frankfurt, Germany - Simon Thompson, University of Kent, UK - Stephanie Weirich, University of Pennsylvania, USA - Steve Zdancewic, University of Pennsylvania , USA Venue The 27th IFL will be held in association with the Faculty of Computer Science, University of Koblenz-Landau, Campus Koblenz. Koblenz is well connected by train to several international airports. For instance, Koblenz can be reached from Frankfurt by high-speed train ICE within an hour. The modern Koblenz campus is close to the city center and can be reached by foot, bus, or cab. See the website for more information on the venue. Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson(a)kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt

1 0

[Jobs] Galois is hiring
by Iavor Diatchki 05 May '15

05 May '15

Hello, Galois is hiring! We're looking for researchers, principal investigators, software engineers, and project leads with expertise in functional programming, formal methods, computer security, control systems, or networking. Positions are available at both our Portland OR and Arlington VA offices. For more information on the application process and the available positions, please visit out web site: http://corp.galois.com/careers -Iavor

1 0

Parsing YAML with varying structure
by Johannes Strecha 05 May '15

05 May '15

Dear Cafe, I need help parsing YAML files with varying structure. The minimal example is: a yaml file that has one key, which can hold either one key-value pair or two key value pairs. I have data types for the one key, and the two possible sub-keys: >data Var = Var { > v' :: Either MyList Item > } deriving Show > >data MyList = MyList { > a' :: Int, > b' :: Int > } deriving Show > >data Item = Item { > content' :: String > } deriving Show To read MyList and Item from the file I wrote FromJSON instances >instance FromJSON MyList where > parseJSON (Object m) = MyList <$> m .: (pack "a") <*> m .: (pack "b") > parseJSON x = fail ("not an object: " ++ show x) > >instance FromJSON Item where > parseJSON (Object m) = Item <$> m .: (pack "c") > parseJSON x = fail ("not an object: " ++ show x) I also have read functions for MyList and Item: >readItem :: IO Item >readItem = either (error.show) id <$> decodeFileEither "test.yaml" > >readMyList :: IO MyList >readMyList = either (error.show) id <$> decodeFileEither "test.yaml" The file test.yaml looks like >v: > a: 4 > b: 5 or, alternatively >v: > c: "test" The question is how I can decode test.yaml to get Var. Trying to code readVar like readItem (having FromJSON Var like FromJSON Item) failed. For convenience I attached the relevant source files. Regards, Johannes.

2 2

ANN: applicative-fail-1.0.0
by Alexey Uimanov 05 May '15

05 May '15

Hi guys, here is reworked applicative-fail http://hackage.haskell.org/package/applicative-fail-1.0.0 You can use it to e.g. parse requests in your web application, or in any other parse-like stuff.

4 3