News aggregator

Multiway tree vs rose tree

haskell-cafe - Mon, 05/11/2015 - 1:50pm
Hi - I am new to this list, and the only archive I could find is the Mailman archive, which is next to impossible to search. So this may be a topic that has been previously discussed, I don't know... The documentation at https://hackage.haskell.org/package/containers-0.3.0.0/docs/Data-Tree.html says that a rose tree is another name for multiway tree. But this is not true according to my understanding of the accepted definition in the CS literature (see e.g. http://doc.utwente.nl/66626/1/db-utwente-0000003528.pdf) Rose trees do not have labels at the nodes, only at the leaves (aka tips). There is another page https://wiki.haskell.org/Algebraic_data_type#Rose_tree that also uses this divergent definition. To further propagate this problem, the Wikipedia page https://en.wikipedia.org/wiki/Rose_tree uses these Haskell wiki pages as the definitive source. Tara
Categories: Offsite Discussion

using scoped type variables in proofs...

haskell-cafe - Mon, 05/11/2015 - 11:33am
Hello, I have written the below proof as an exercise. I want to explicitly annotate the proof with type variables.....but I cant get a line to work... here a nice plus lets try to do If I prove its abelian then we get it... the "proof" works if we remove the type annotation but I want the annotation to convince myself I know whats going on. THE COMMENTED LINE FAILS. Could not deduce ((b1 :+ 'S a1) ~ (a2 :+ 'S a1)) from the context (a ~ 'S a1) bound by a pattern with constructor SS :: forall (a :: Nat). SNat a -> SNat ('S a), in an equation for 'theoremPlusAbelian' at Cafe2.lhs:57:24-27 or from (b ~ 'S a2) bound by a pattern with constructor SS :: forall (a :: Nat). SNat a -> SNat ('S a), in an equation for 'theoremPlusAbelian' at Cafe2.lhs:57:45-48 NB: ':+' is a type function, and may not be injective The type variable 'b1' is ambiguous Expected type: (a :+ a2) :== (a2 :+ a) Actua
Categories: Offsite Discussion

Automated Differentiation of Matrices (again)

haskell-cafe - Mon, 05/11/2015 - 11:24am
In [1](this) email thread Edward Kmett and Dominic Steinitz discuss the state of interoperability of `ad` and `hmatric` (or `repa`) with Edward hinting that the 4.0 line of `ad` might improve on the situation. Could someone elaborate on the state of affairs two years later? Florian [1]: https://mail.haskell.org/pipermail/haskell-cafe/2013-April/107561.html _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Categories: Offsite Discussion

Introduction to Type Inference

Haskell on Reddit - Mon, 05/11/2015 - 10:24am
Categories: Incoming News

GHC Weekly News - 2015/05/11

Haskell on Reddit - Mon, 05/11/2015 - 10:11am
Categories: Incoming News

The GHC Team: GHC Weekly News - 2015/05/11

Planet Haskell - Mon, 05/11/2015 - 8:49am

Hi *,

It's been a few weeks since the last news bulletin - this is the result of mostly quietness on behalf of the list and developers, and some sickness on behalf of your editor for several days there. But now there's actually some things to write here!

The past few weeks, GHC HQ has been having some quiet meetings mostly about bugfixes for a 7.10.2 release - as well as noodling about compiler performance. Austin has begun compiling his preliminary notes on the wiki, under the CompilerPerformance page, where we'll be trying to keep track of the ongoing performance story. Hopefully, GHC 7.12.1 will boast a bit better performance numbers.

There are a lot of users who are interested in this particular pain point, so please file tickets and CC yourself on bugs (like #10370), or feel free to help out!

7.10.2 status

There's been a bit of chatter about the lists about something on many peoples mind: the release of GHC 7.10.2. Most prominently, Mark Lentczner popped in to ask when the next GHC release will happen - in particular, he'd like to make a Haskell Platform release in lockstep with it (see below for a link to Mark's email).

Until recently, the actual desire for 7.10.2 wasn't totally clear, and at this point, GHC HQ hasn't firmly committed to the 7.10.2 release date. But if milestone:7.10.2 is any indicator, we've already closed over three dozen bugs, several of them high priority - and they keep coming in. So it seems likely people will want these fixes in their hands relatively soon.

Just remember: if you need a fix for 7.10.2, or have a bug you need us to look at, please email the ghc-devs list, file a ticket, and get our attention! Just be sure to set the milestone to 7.10.2.

List chatter
  • Niklas Hambüchen announced that he's backported the recent lightweight stack-trace support in GHC HEAD to GHC 7.10 and GHC 7.8 - meaning that users of these stable release can have informative call stack traces, even without profiling! FP Complete was interested in this feature, so they'd probably love to hear user input. ​https://mail.haskell.org/pipermail/ghc-devs/2015-April/008862.html
  • David Terei has written up a proposal on reconciling the existence of Roles with Safe Haskell, which caused us a lot of problems during the 7.8 release cycle. In particular, concerning the ability to break module abstractions and requiring programmers to safeguard abstractions through careful use of roles - and David's written a proposal to address that. ​https://mail.haskell.org/pipermail/ghc-devs/2015-April/008902.html
  • Mark Lentczner started a thread about the 7.10.2 release schedule - because this time, he wants to do a concurrent Haskell Platform release! The thread ended up with a good amount of discussion concerning if 7.10.2 is even needed - but at this rate, it looks like it will ship sometime soon. ​https://mail.haskell.org/pipermail/ghc-devs/2015-May/008904.html
  • Mateusz Kowalczyk posted to ghc-devs hoping to get some help with a tricky, long-standing issue: #4012, which concerns the determinism of GHC binaries. It turns out GHC isn't entirely deterministic when it calculates package IDs, meaning things get really bad when you mix prebuilt binary packages for systems. This in particular has become a real problem for the Nix package manager and users of Haskell applications. Mateusz asks if anyone would be willing to help look into it - and a lot of people would appreciate the help! ​https://mail.haskell.org/pipermail/ghc-devs/2015-May/008992.html
Noteworthy commits Closed tickets

#10293, #10273, #10021, #10209, #10255, #10326, #9745, #10314, #8928, #8743, #10182, #10281, #10325, #10297, #10292, #10304, #10260, #9204, #10121, #10329, #9920, #10308, #10234, #10356, #10351, #10364, #9564, #10306, #10108, #9581, #10369, #9673, #10288, #10260, #10363, #10315, #10389, #9929, #10384, #10382, #10400, #10256, #10254, #10277, #10299, #10268, #10269, #10280, #10312, #10209, #10109, #10321, #10285, #9895, #10395, #10263, #10293, #10210, #10302, #10206, #9858, #10045, and #9840.

Categories: Offsite Blogs

Recursion Schemes

Haskell on Reddit - Mon, 05/11/2015 - 6:00am
Categories: Incoming News

Is this functional reactive programming

haskell-cafe - Mon, 05/11/2015 - 1:36am
What I want to be able to do is something like this: do x <- newSTRef 2 y <- newSTRef 3 z <- letSTRef (x + y) r1 <- readSTRef z writeSTRef x 5 r2 <- readSTRef z return (r1, r2) This should return (6,15) The "letSTRef" is what's new. The value it returns can change based on the parts that make up it's function changing. I understand this syntax above isn't going to work (I'd have to use applicative at least I'd imagine) but my main question is that does something like this exist? Is it functional reactive programming or is it something else? I don't want to be reinventing the wheel if this type of idea is already implemented but I haven't recognised it. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Categories: Offsite Discussion

FLOPS 2016, promoting cross-fertilization across the whole declarative programming and theory and practice

Lambda the Ultimate - Mon, 05/11/2015 - 1:16am
LtU generally is not appropriate venue for posting call-for-papers, but there have been exceptions, if the CFP has an exceptionally wide appeal. Hopefully FLOPS 2016 might qualify.
http://www.info.kochi-tech.ac.jp/FLOPS2016/

FLOPS has been established to promote cooperation between logic and functional programmers, hence the name. This year we have taken the name exceptionally seriously, to cover the whole extent of declarative programming, which also includes program transformation, re-writing, and extracting programs from proofs of their correctness. There is another strong emphasis: on cross-fertilization among people developing theory, writing tools and language systems using that theory, and the users of these tools. We specifically ask the authors to make their papers understandable by the wide audience of declarative programmers and researchers.

As you can see from the Program Committee list, the members have done first-rate theoretic work, and are also known for their languages, tools and libraries. PC will appreciate the good practical work. Incidentally, there is a special category, ``System Descriptions'' that FLOPS has always been known for. We really want to have more submissions in that category.

One can see even on LtU that there is some rift between theoreticians and practitioners: Sean McDermid messages come to mind. He does have many good points. We really hope that FLOPS will help repair this rift.

Categories: Offsite Discussion

Simple import-counter to help understand codebases

Haskell on Reddit - Sun, 05/10/2015 - 10:03pm

https://gist.github.com/mitchellwrosen/049352bd23357be322d7

Whenever I'm reading over a codebase I like to start at the modules with the least in-project dependencies, so I wrote this simple script. Example usage:

./explore ~/auto/src 0 Control.Auto.Blip.Internal 1 Control.Auto.Blip 1 Control.Auto.Interval 1 Control.Auto.Serialize 2 Control.Auto.Generate 2 Control.Auto.Process 2 Control.Auto.Run 5 Control.Auto.Effects 5 Control.Auto.Switch 9 Control.Auto.Time 11 Control.Auto.Process.Random 37 Control.Auto

Here, I'd start with Control.Auto.Blip and work my way up the abstraction hierarchy.

Hopefully this is useful to someone else! And if you can make this work for mutually recursive modules... I love you.

submitted by MitchellSalad
[link] [7 comments]
Categories: Incoming News

First Call for Papers for IFL 2015

haskell-cafe - Sun, 05/10/2015 - 9:02pm
Hello, Please, find below the first call for papers for IFL 2015. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL --- 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. A
Categories: Offsite Discussion

First Call for Papers for IFL 2015

General haskell list - Sun, 05/10/2015 - 9:02pm
Hello, Please, find below the first call for papers for IFL 2015. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL --- 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. A
Categories: Incoming News

FP Complete: Secure package distribution: ready to roll

Planet Haskell - Sun, 05/10/2015 - 6:00pm

We're happy to announce that all users of Haskell packages can now securely download packages. As a tl;dr, here are the changes you need to make:

  1. Add the relevant GPG key by following the instructions
  2. Install stackage-update and stackage-install: cabal update && cabal install stackage
  3. From now on, replace usage of cabal update with stk update --verify --hashes
  4. From now on, replace usage of cabal install ... with stk install ...

This takes advantage of the all-cabal-hashes repository, which contains cabal files that are modified to contain package hashes and sizes. The way we generate the all-cabal-hashes is interesting in its own right, but I won't shoehorn that discussion into this blog post. Wait for a separate blog post soon for a description of our lightweight architecture for this.

Note that this is an implementation of Mathieu's secure distribution proposal, with some details modified to work with the current state of our tooling (i.e., lack of package hash information from Hackage).

How it works

The all-cabal-hashes repository contains all of the cabal files Hackage knows about. These cabal files are tweaked to have a few extra metadata fields, including cryptographic hashes of the package tarball and the size of the package, in bytes. (It also contains the same data in a JSON file, which is what we currently use due to cabal issue #2585.) There is also a tag on the repo, current-hackage, which always points at the latest commit and is GPG signed. (If you're wondering, we use a tag instead of just commit signing since it's easier to verify a tag signature.)

When you run stk update --verify --hashes, it fetches the latest content from that repository, verifies the GPG signature, generates a 00-index.tar file, and places it in the same location that cabal update would place it. At this point, you have a verified package index on your location machine, which contains cryptographic signatures and sizes for each package tarball.

Now, when you run stk install ..., the stackage-install tool handles all downloads for you (subject to some caveats, like cabal issue #2566). stackage-install will look up all of the hashes and sizes that are present in your package index, and verify them during download. In particular:

  • If the server tries to send more data than expected, the download stops immediately and an exception is thrown.
  • If the server sends less data than expected, an exception is thrown.
  • If the hash does not match what was expected, an exception is thrown.

Only when the hash and size match does the file get written. In this way, tarballs are only made available to the rest of your build tools after they have been verified.

What about Windows?

In mailing list discussions, some people were concerned about supporting Windows, in particular that Git and GPG may be difficult to install and configure on Windows. But as I shared on Google+ last week, MinGHC will now be shipping with both of those tools. I've tested things myself on Windows with the new versions of MinGHC, stackage-update, and stackage-install, and the instructions above worked without a hitch.

Of course, if others discover problems- either on Windows or elsewhere- please report them so they can be fixed.

Speed and reliability

In addition to the security benefits of this tool chain, there are also two other obvious benefits. By downloading the package index updates via Git, we are able to download only the differences since the last time we downloaded. This leads to less bandwidth usage and a quicker download.

This toolchain also replaces connections to Hackage with two high reliability services: Amazon S3 (which holds the package contents) and Github. Using off the shelf, widely used services in place of hosting everything ourself reduces our community burden and increases our ecosystem's reliability.

Caveats

There are unfortunately still some caveats with this.

  • The biggest hole in the fence is that we have no way of securing distribution of packages from Hackage itself. While all-cabal-hashes downloads the package index from Hackage via HTTPS (avoiding MITM attacks), there are still other attack vectors to be concerned about (such as breaching the Hackage server itself). The improved Hackage security page documents many of these concerns. Ideally, Hackage would be modified to perform package index signing itself.
  • Due to cabal issue #2566, it's still possible that cabal-install may download packages for you instead of stackage-install, though these situations should be rare. Hopefully integrating this download code directly with a build tool will eliminate that weakness.
  • There is still no verification of package author signatures, so that if someone's Hackage credentials are compromised (which is unfortunately very probable), a corrupted package could be present. This is something Chris Done and Tim Dysinger are working on. We're looking for others in the community to work with us on pushing forward on this. If you're interested, please contact us.
Using preexisting tools

What's great about this toolchain is how shallow it is. All of the heavy lifting is handled by Git, GPG, Amazon S3, Github, and (as you'll see in a later blog post) Travis CI. We mostly just wrap around these high quality tools and services. Not only was this a practical decision (reduce development time and code burden), but also a security decision. Instead of creating a Haskell-only security and distribution framework, we're reusing the same components that are being tried and tested on a daily basis by the greater software community. While this doesn't guarantee the tooling we use is bug free, it does mean that the "many eyeballs" principle applies.

Using preexisting tools also means that we open up the possibility of use cases never before considered. For example, someone contacted me (anonymity preserved) about a use case where he wanted to be able to identify which version of Hackage was being used. Until now, such a concept didn't exist. With a Git-based package index, the Hackage version can be identified by its commit.

I'm sure others will come up with new and innovative tricks to pull off, and I look forward to hearing about them.

Categories: Offsite Blogs

(Beginner) Integrating Persistent and Scotty, parts II and III

Haskell on Reddit - Sun, 05/10/2015 - 3:07pm

Last week I wrote a post on integrating Persistent and Scotty, and received a lot of great feedback. I've been working on integrating the feedback since, and figured I'd post my findings:

Part II: The Yak Shavening

In this episode, I discovered why it's critical to keep code compartmentalized. There was some language pragma that was required for Persistent that was conflicting with the scottyT function, and the result was a type error I couldn't understand (and seemingly unGoogleable). I'm planning on posting a complete minimal reproduction to get more insight.

Part III: The It Worksening

And in this, I managed to wire up the Reader monad stack, working up my understanding on how these transformer things work.

The Github repository that hosts the code is here: https://github.com/parsonsmatt/scotty-persistent-example

I'd love any suggestions, feedback, etc. I personally found that writing out my learning experience was really helpful for solidifying what i was learning, and I hope that it can be useful for others.

submitted by ephrion
[link] [5 comments]
Categories: Incoming News

[ANN] servant 0.4.0 released (+new website)

haskell-cafe - Sun, 05/10/2015 - 1:38pm
Hello everyone, We're happy to announce the releases of: - servant 0.4.0 - servant-server 0.4.0 - servant-client 0.4.0 - servant-jquery 0.4.0 - servant-docs 0.4.0 - servant-blaze 0.4.0 - servant-lucid 0.4.0 to Hackage. As well as a new website, same URL as before: http://haskell-servant.github.io/ -- which features a tutorial that's much more informative than the getting started we had for the previous version. The tutorial is available at http://haskell-servant.github.io/tutorial The highlights for this release are: - Multiple content-types support (with servant-blaze and servant-lucid offering a way to encode data for the HTML content type) - Handlers in other monads than `EitherT` - Response headers support - Safe links to endpoints - Saner types for aborting early in request handlers (the `Left` branch in `EitherT`) For more details about the new features, please read the release post: http://haskell-servant.github.io/posts/2015-05-10-servant-0.4-released.html Cheers
Categories: Offsite Discussion

servant 0.4 released

Haskell on Reddit - Sun, 05/10/2015 - 6:39am
Categories: Incoming News