May 2015 - Haskell-Cafe

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...(a)snoyman.com> wrote: >> > >> > >> > On Sat, Apr 18, 2015 at 12:20 AM Bardur Arantsson >> > <sp...(a)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...(a)haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskel...(a)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 04 May '15

04 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 04 May '15

04 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 04 May '15

04 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

Improvements to package hosting and security
by Michael Snoyman 03 May '15

03 May '15

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… [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

14 42

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

03 May '15

Define "superior"? As argued in the proposal, the salient features are that by devolving practically everything to Git+GPG, we end up with less code to maintain in our tooling, less code to maintain in our infrastructure (namely hackage-server), a more reliable service, and a smaller chance of buggering up security related activities (such as signing and managing trust). We're not introducing dependencies on dynamically linked system libraries that makes tooling hard to distribute. We're not asking users to install anything new that isn't already a staple of most developer desktops, and not asking users, Hackage trustees and Hackage admins to manage new identities with new key formats that aren't the existing ones they already have (namely GnuPG). Further, users can still opt-out of signature verification if they want to. Compared to alternative approaches - there has been a proposal to get incremental updates à la Git differently by growing (potentially infinitely) the end of a tar file served by the server via HTTP. This means grabbing the history for new package revisions cannot be opted out from easily. With Git, you get this for free, since users can `git clone --depth=1` and still be able to do a `git pull` later and verify signatures. You further get the advantage of being able to directly mine the history of changes, using standard tools, something that can't be done directly on the tar file without more custom tooling (or post conversion to Git). On 28 April 2015 at 23:33, Bardur Arantsson <spam(a)scientician.net> wrote: > On 28-04-2015 23:09, Mathieu Boespflug wrote: > > [removing erroneous haskell-cafe(a)googlegroups.com from To list.] > > (I'm not the person you're responing to. From the mail-headers, I can't > see the person(s) you're responding to, but so be it.) > > Do you have evidence that your approach is superior, and could you > please cite it? [Or, alternatively provide negative evidence for > $OTHER_APPROACH.]) > > Regards, > > -- > 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/mhouaf%24it2%241%40ger.… > . > For more options, visit https://groups.google.com/d/optout. >

5 6

Meet some problem when installing Agda
by Zongzhe Yuan 02 May '15

02 May '15

Hi I want to use Agda on my computer and I follow the instruction http://wiki.portal.chalmers.se/agda/pmwiki.php?n=Main.MacOSX However when I was using cabal install Agda to install agda, the terminal said The program cpphs version >=1.18.6 && <1.19 is required but the version found at /Users/XXXXXX/Library/Haskell/bin/cpphs is version 1.19 Do you have some idea how could i fix that problem? Zongzhe Yuan This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

2 1

Is it acceptable if Applicative behave not like a Monad
by Alexey Uimanov 02 May '15

02 May '15

Hello, I have such a question: assume you have some type `T` which has Applicative and Monad instances. Is it ok if code like this: foo :: Int -> T String bar :: Int -> T Int (,) <$> foo 10 <*> bar "20" behaves not like this code: foobar = do x <- foo 10 y <- bar "20" return (x, y) The word "behaves" I mean not just returning value but the effect performed also.

10 10