News aggregator

Upcoming GHC version (was: Re: Drastic Prelude changes imminent)

libraries list - Wed, 01/28/2015 - 1:16am
If BBP is going to be released as-is, can we please call the next release GHC 8.0? Good stuff: http://semver.org/ Thanks, Greg On Tue, Jan 27, 2015 at 10:22 AM, David Luposchainsky <dluposchainsky< at >googlemail.com> wrote:
Categories: Offsite Discussion

Using GHC API to compile Haskell sources to CORE andCORE to binary

haskell-cafe - Wed, 01/28/2015 - 1:10am
Hello All! :) Recently I've came across a problem and hopefully you could help me with it. Basically I and some people here are running a startup and we have created a language for processing images. This language has 2 interchangeable representations - textual and visual, dataflow one. Right now we are compiling it to haskell sources, but we want to move over GHC CORE. Getting into GHC has a high learning curve, as far as we see, and we would be very thankfull for any help with a minimal working example of compiling haskell sources to CORE and then CORE to binaries. I've posted couple days ago a detailed question on StackOverflow, here: http://stackoverflow.com/questions/28059669/using-ghc-api-to-compile-haskell-sources-to-core-and-core-to-binary I would be very thankful for any help or hints! All the best, Wojciech _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Categories: Offsite Discussion

runSubStateT

haskell-cafe - Wed, 01/28/2015 - 12:14am
runSubStateT :: Monad m => (s -> s') -> (s' -> s) -> StateT s' m a -> StateT s m a runSubStateT to from m = StateT (\s -> liftM (\(a,s') -> (a,from s')) (runStateT m (to s))) Anyone ever needed something like this? Does it already exist in some form in the standard libraries? Ciao
Categories: Offsite Discussion

CFP: WPTE 2015 Second International Workshop on Rewriting Techniques for Program Transformations and Evaluation

General haskell list - Tue, 01/27/2015 - 8:06pm
FIRST CALL FOR PAPERS Second International Workshop on Rewriting Techniques for Program Transformations and Evaluation WPTE 2015 affiliated with RDP 2015 2 July, 2015, Warsaw, Poland http://www.trs.cm.is.nagoya-u.ac.jp/event/wpte2015/ Aims and Scope ============== The aim of WPTE is to bring together the researchers working on program transformations, evaluation, and operationally-based programming language semantics, using rewriting methods, in order to share the techniques and recent developments and to exchange ideas to encourage further activation of research in this area. The previous WPTE was held in Vienna 2014. Topics of interest in the scope of this workshop include: * Correctness of program transformations, optimizations and translations. * Program transformations for proving termination, confluence and other properties. * Correctness of ev
Categories: Incoming News

Error trying to re-upload to the Haskell wiki

haskell-cafe - Tue, 01/27/2015 - 7:30pm
L.S., I am trying to upload a file to the Haskell wiki again, after I deleted it (the description was wrong and there is no option to edit the description). Every time I try this, I get the message: Remote server or file not found You tried to access the address https://wiki.haskell.org/Special:Upload, which is currently unavailable. The file is not visible in the upload log. How can I upload this file again? Regards, Henk-Jan van Tuyl
Categories: Offsite Discussion

Representation of lenses

haskell-cafe - Tue, 01/27/2015 - 7:18pm
Hi, I'm planning on discussing lenses with some colleagues shortly so I'm consolidating some of my notes into a coherent story. At one point I found myself describing lenses as a way of packaging up a getter and a setter into a single thing. However, this raises the question: why not just use a pair (getter, setter)? More precisely, I believe that the types (a -> s, s -> a -> a) and (forall f. Functor f => (s -> f s) -> a -> f a) are isomorphic. Is that right? I see that one advantage of the lens type is that you can use (.) to compose them since they're just functions, but that doesn't bother me much and it seems I could define another operator to compose (getter, setter) lenses and the rest of the machinery would work either way. It's also possible that you can't get the full generality of (forall f. (s -> f t) -> a -> f b) lenses with getter/setter pairs, although I haven't worked through the details yet so don't know either way. So, my question is: what is the advantage of representing lenses in the
Categories: Offsite Discussion

Help finding one-sided ordered list implementation

haskell-cafe - Tue, 01/27/2015 - 7:04pm
In "Numerical Representations as Higher-Order Nested Datatypes", Ralf Hinze describes an implementation of one-sided ordered lists as 2-3 search trees under the left spine view. I'm wondering if anyone's actually coded those up somewhere I could download them, or if I'll have to dig into all the details in the paper and write them myself. Thanks, David
Categories: Offsite Discussion

Looking for feedback - emulating a 1-bit register with a Neural Network

Haskell on Reddit - Tue, 01/27/2015 - 6:39pm

I wrote a bit of background about the project over at /r/compsci: http://www.reddit.com/r/compsci/comments/2tw5vc/emulating_a_1bit_register_with_a_neural_network/

I'm pretty new to Haskell so I'm sure there are lot's of problems. The repo can be found here: https://bitbucket.org/rickdzekman/memnet

I was hoping to get some feedback on my Haskell implementation. Though if you have any general comments about the concept I'm keen to hear them.

Some things that I think are weaknesses:

  • I don't encapsulate the non-termination aspect at all. I've looked at IterT as well as Pipes, but I settled on writing a simple loop.
  • I also wrote my own Semaphores using MVars instead of using something like Pipes.
  • The way inputs/outputs are passed to/from the network is a bit haphazard. I basically take a number, convert it to bits, map those bits to node IDs in the network, and then do the inverse for outputs. It might have been easier to actually use bits, where as I used Bools.
  • I've been told I should look into Vectors rather than Arrays for my mutable state.This proof of concept is so basic that I didn't look at performance at all. But my Node type is so simple, that apparently I should be able to use Unboxed Vectors.

I'm aware the GUI is terrible! I'm on Windows and had heaps of trouble with GTK. When I finally did get it up and running the non-termination of my main program caused GTK to crash. Gloss on the other hand was really simple to setup.

I've had a few raised eyebrows about the way I mix IO and ST. Perhaps it's my imperative background coming through here. But I use an STArray to avoid copying the entire network of Node's each time they pass a message between each other (considering the network is cyclic, it also avoids passing the knot). I then thread the state within an IO loop, extracting output information via runSTArray. That particular bit is here: https://bitbucket.org/rickdzekman/memnet/src/6f3006e39405f91d53dc278dd4d2bc4e2c4a5756/src/AI/MemNet/RunMemNet.hs?at=master

As a Haskell newbie (who also isn't a professional programmer) I would really appreciate some feedback from the more knowledgeable people out there.

submitted by rick_dz
[link] [2 comments]
Categories: Incoming News

The GHC Team: GHC Weekly News - 2015/01/27

Planet Haskell - Tue, 01/27/2015 - 3:03pm

Hi *,

It's time for some GHC Weekly news!

  • Austin took the time the past week to check `./validate --slow` failures, and is planning on filing bugs and fixes for the remaining failures soon. Afterwords, we'll immediately begin enabling --slow on Phabricator, so developers get their patches tested more thoroughly.
  • The 7.10 release looks like it will likely not have a 3rd Release Candidate, and will be released in late Feburary of 2015, as we originally expected.
  • The 7.10 branch currently has two showstopping bugs we plan on hitting before the final release. And we'd really like for users to test so we can catch more!
  • Austin Seipp will likely be gone for the coming week in a trip to New York City from the 28th to the 4th, meaning (much to the dismay of cheering crowds) you'd better catch him beforehand if you need him! (Alternatively Austin will be held back due to an intense snowstorm developing in NYC. So, we'll see!)
  • Austin is planning on helping the LLVM support in HEAD soon; after coordinating with Ben Gamari, we're hoping to ship GHC 7.12 with (at least) LLVM 3.6 as an officially supported backend, based on the documentation described in ​https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend - lots of thanks to Ben for working with upstream to file bugs and improve things!

And in other news, through chatter on the mailing list and Phabricator, we have:

  • Peter Trommler posted his first version of a native Linux/PowerPC 64bit code generator! There's still a lot more work to do, but this is a significantly improved situation over the unregisterised C backend. Curious developers can see the patch at ​Phab:D629.
  • A long, ongoing thread started by Richard Eisenberg about the long-term plans for the vectorisation code have been posted. The worry is that the vectoriser as well as DPH have stagnated in development, which costs other developers any time they need to build GHC, make larger changes, or keep code clean. There have been a lot of varied proposals in the thread from removing the code to commenting it out, to keeping it. It's unclear what the future holds, but the discussion still rages on. ​https://www.haskell.org/pipermail/ghc-devs/2015-January/007986.html
  • Alexander Vershilov made a proposal to the GHC team: can we remove the transformers dependency? It turns out to be a rather painful dependency for users of the GHC API and of packages depending on transformers, as you cannot link against any version other than the one GHC ships, causing pain. The alternative proposal involves splitting off the transformers dependency into a package of Orphan instances. The final decision isn't yet clear, nor is a winner in clear sight yet! ​https://www.haskell.org/pipermail/ghc-devs/2015-January/008058.html
  • Simon Marlow has started a long thread about the fate of records in future GHC versions. Previously, Adam Gundry had worked on OverloadedRecordFields. And now Nikita Volkov has introduced his records library which sits in a slightly different spot in the design space. But now the question is - how do we proceed? Despite all prior historical precedent, it looks like there's finally some convergence on a reasonable design that can hit GHC in the future. ​https://www.haskell.org/pipermail/ghc-devs/2015-January/008049.html

Closed tickets the past two weeks include: #9889, #9384, #8624, #9922, #9878, #9999, #9957, #7298, #9836, #10008, #9856, #9975, #10013, #9949, #9953, #9856, #9955, #9867, #10015, #9961, #5364, #9928, and #10028.

Categories: Offsite Blogs

The GHC Team: weekly20150127

Planet Haskell - Tue, 01/27/2015 - 3:01pm

Hi *,

It's time for some GHC Weekly news! <Insert funny Austin-ish blurb>

  • Austin took the time the past week to check `./validate --slow` failures, and is planning on filing bugs and fixes for the remaining failures soon. Afterwords, we'll immediately begin enabling --slow on Phabricator, so developers get their patches tested more thoroughly.
  • The 7.10 release looks like it will likely not have a 3rd Release Candidate, and will be released in late Feburary of 2015, as we originally expected.
  • The 7.10 branch currently has two showstopping bugs we plan on hitting before the final release. And we'd really like for users to test so we can catch more!
  • Austin Seipp will likely be gone for the coming week in a trip to New York City from the 28th to the 4th, meaning (much to the dismay of cheering crowds) you'd better catch him beforehand if you need him! (Alternatively Austin will be held back due to an intense snowstorm developing in NYC. So, we'll see!)
  • Austin is planning on helping the LLVM support in HEAD soon; after coordinating with Ben Gamari, we're hoping to ship GHC 7.12 with (at least) LLVM 3.6 as an officially supported backend, based on the documentation described in ​https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend - lots of thanks to Ben for working with upstream to file bugs and improve things!

And in other news, through chatter on the mailing list and Phabricator, we have:

  • Peter Trommler posted his first version of a native Linux/PowerPC 64bit code generator! There's still a lot more work to do, but this is a significantly improved situation over the unregisterised C backend. Curious developers can see the patch at ​Phab:D629.
  • A long, ongoing thread started by Richard Eisenberg about the long-term plans for the vectorisation code have been posted. The worry is that the vectoriser as well as DPH have stagnated in development, which costs other developers any time they need to build GHC, make larger changes, or keep code clean. There have been a lot of varied proposals in the thread from removing the code to commenting it out, to keeping it. It's unclear what the future holds, but the discussion still rages on. ​https://www.haskell.org/pipermail/ghc-devs/2015-January/007986.html
  • Alexander Vershilov made a proposal to the GHC team: can we remove the transformers dependency? It turns out to be a rather painful dependency for users of the GHC API and of packages depending on transformers, as you cannot link against any version other than the one GHC ships, causing pain. The alternative proposal involves splitting off the transformers dependency into a package of Orphan instances. The final decision isn't yet clear, nor is a winner in clear sight yet! ​https://www.haskell.org/pipermail/ghc-devs/2015-January/008058.html
  • Simon Marlow has started a long thread about the fate of records in future GHC versions. Previously, Adam Gundry had worked on OverloadedRecordFields. And now Nikita Volkov has introduced his records library which sits in a slightly different spot in the design space. But now the question is - how do we proceed? Despite all prior historical precedent, it looks like there's finally some convergence on a reasonable design that can hit GHC in the future. ​https://www.haskell.org/pipermail/ghc-devs/2015-January/008049.html

Closed tickets the past two weeks include: #9889, #9384, #8624, #9922, #9878, #9999, #9957, #7298, #9836, #10008, #9856, #10009, #10011, #9975, #10013, #9949, #9953, #9856, #9955, #9867, #10015, #9961, #5364, #9928, and #10028.

Categories: Offsite Blogs

Multi-pattern LambdaCase?

haskell-cafe - Tue, 01/27/2015 - 2:38pm
Is there a particular reason that LambdaCase does not support muliple patterns? Specifically I am suggesting that \case { pA1 pA2 pA3 -> eA, ... } be sugar for \freshName1 freshName2 freshName3 -> case freshName1 freshName2 freshName3 of { pA1 pA2 pA3 -> eA, ... } Is there some technical reason that prevents it? Tom
Categories: Offsite Discussion

Drastic Prelude changes imminent

General haskell list - Tue, 01/27/2015 - 12:52pm
If you didn't know that, e.g., the type of foldr is changing, check out the thread https://www.haskell.org/pipermail/libraries/2015-January/024777.html. This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html Insofar as this communication contains any market commentary, the market commentary has been prepared by a sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utili
Categories: Incoming News

Drastic Prelude changes imminent

libraries list - Tue, 01/27/2015 - 12:32pm
The next version (7.10) of GHC is slated to have a drastically changed Prelude. This message is very late in the release process, but I would urge caution before changing. The changes are (aptly) named the Burning Bridges Proposal (BBP). Even though the work has been going on for a while, it seems that this change is coming as a surprise to many people (including Simon Peyton Jones). In summary, it generalizes many list operation, e.g., foldr, to be overloaded. There is much to welcome in BBP, but changing the Prelude cannot be done lightly since it really is like changing the language. So I think it's really important for a large number of people to be able to try out such changes before they come into effect, and to have time to let the changes stabilize (you rarely get it right the first time). I've discussed this with a number of people, including Simon PJ, and we have concrete proposals. Proposal 1: * Add a new pragma {-# LANGUAGE Prelude=AlternativePrelude #-} * This is a new fe
Categories: Offsite Discussion

Why don't all new languages use (functor,monad,etc) abstractions in there main libraries?

Haskell on Reddit - Tue, 01/27/2015 - 12:05pm

It always bother me. Even if language have side effects and doesn't really need IO, almost every language will have Maybe, List, Cont, etc so they need map, bind, etc. Why don't they use well known abstractions?

submitted by dotneter
[link] [40 comments]
Categories: Incoming News

How to force James Cook (author of dependent-map)evaluation?

haskell-cafe - Tue, 01/27/2015 - 12:01pm
Hello people. There is a pull request https://github.com/mokus0/dependent-map/pull/2 which I need to be on hackage. I have sent a email to mokus< at >deepbondi.net but nothing happened. Does anyone can contact with James and tell him about my problem? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Categories: Offsite Discussion