News aggregator

best practice for lifting of IO and could lifting beautomated?

haskell-cafe - Mon, 10/26/2015 - 12:03pm
Dimitri DeFigueiredo wrote: For this particular example, the answer is easy: If you have the IO monads, you have the Reader monad, and the State/Writer as well. This is just an IORef. Using just IO, you can get State, Reader, Writer, and Exception (and in a modular way!) As to you general question, I will and do advocating abandoning monad transformers altogether. The paper on extensible effects demonstrated a new solution to the MonadCatchIO problem that solved the long-standing issue of discarding state upon exception. See Sec 6 of
Categories: Offsite Discussion

Five more days: Call for Contributions: BOB 2016 - Berlin, Feb 19, 2016

haskell-cafe - Mon, 10/26/2015 - 11:11am
The submission deadline for is five days away. We are happy with the submissions so far, but you can always have more. So if you always wanted to look into some library that everybody is fussing about and then tell people what you learned, or if you have this trick or you wrote that piece of code that you are fond of, please take a minute to check out our submission guidelines this week. (We have speaker grants for under-represented groups.) cheers, m.
Categories: Offsite Discussion

FP Lunch: Creating Personal Ambitions

Planet Haskell - Mon, 10/26/2015 - 9:10am

Most of us become paralyzed by concern when it comes to truly treading out and doing something about our aspiration. The life we wish is visualized by us, we find out about our people carrying it out and think that somehow they’re extra ordinary or involve some super-human power that makes them in a position to live our aspiration out. The fact remains which they simply began going. There are certainly a lot of individuals who like to compose and want notify to stimulate or educate their given industry on their unique attention. These folks actually cease themselves possibly dreaming about doing this for a living since they just cant work out how to get there using their existence. Their lifestyle meaning Oh Ive got youngsters to look after, oh I better get my doctorate degree first, oh Im not fairly enough, oh I dont learn the first in regards to the writing industry. These arent sensible explanations why you cant become a productive published author, these are simply reasons.

Your sign your sign is also named your “rising indicator.” the 2 phrases are interchangeable.

There are effective authors all over the world who arent any prettier, smarter, thicker, or maybe more exclusive than you’re, they are only doers and not just dreamers. Should you would consider oneself a dreamer then you definitely must become a doer! This is actually the self-published author’s evening. Becoming a home- printed writer will be the method you’ll be able to begin and develop a book publishing profession that is productive and lucrative. More and more people so are taking control in their future and are canning their ideas of pursuing traditional book publishing deals and getting self- released experts. You can study a lot of distinct companies that can help you receive your guide printed. I recommend choosing a company that has a simple deal, a simple writing offer which includes most of the thing you need to have a functional, world class book plus one that could give superior discussion on marketing your book to you.

Melanoma guys are unbelievable lovers.

There are various approaches to market your guide and a marketing plan that suits your lifestyle can be definitely developed by you. For example, if you’re a property mommy and you are an expert in health and you need to start to inform people through creating your own book, you are able to produce a book promotional approach that’s more web than basically traveling a lot doing workshops and book signings. My book would be published by me with a firm which was at least able to support me develop a marketing plan if I needed since 90% to become an effective writer of the work may be the marketing and marketing that aid. But dont permit this shock you. If you would like to achieve your dream of being a published publisher then consult with somebody who can provide you on publishing the top & most valuable guide feasible direction and do some investigation about the marketplace and maybe custom essays for sale you just need to consider step one.

Categories: Offsite Blogs

I made a strange visual functional debugger for my minor thesis. Please try it out!

Haskell on Reddit - Mon, 10/26/2015 - 6:45am

TLDR: I have a rather unique debugging task/survey up at, that I'm looking for people to try out.

I'm doing a minor thesis at my university exploring an alternate method of debugging purely functional programs. Computations are represented spatially, with the user being able to incrementally reveal the details of a computation to view all of the intermediate computations taking place.

The project was motivated by my frustrations debugging in Haskell. The tool doesn't actually debug Haskell code though, because in order to implement the tool I essentially had to write my own interpreter for an intermediary language. What I'm actually doing at the moment is transpiling from the compiled JS of a PureScript program to my own format. It's quite a messy beast underneath, but it's intended as a prototype. You don't need to know anything about PureScript, because the original source code is never shown.

I need people to run through a few debugging tasks so I can observe how people use the tool, and what they think about it. It should take about 30 minutes. If you can spare the time to check it out, it would be much appreciated:

Edit: also, if for some reason the survey bugs out on you, please let me know. I'm a novice to web dev! Thanks :)

submitted by -ecl3ctic-
[link] [23 comments]
Categories: Incoming News

mashup of Haskell News and hdiff

haskell-cafe - Mon, 10/26/2015 - 5:17am
Hi all, For Haskell News junkies I created a simple mashup of and Luite Stegeman's hdiff site. It adds a "hdiff" link to all Hackage upload news items so you can conveniently see what changed in the new version. It consists of just an html file and .js file and is available at: ER _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >
Categories: Offsite Discussion

Hackage feature request: show types of names listedin index page

haskell-cafe - Mon, 10/26/2015 - 2:29am
I pretty much said all I wanted to say in the title, but just to rephrase, I think it'd be super helpful if Hackage listed types of names listed in index pages. The reason is because most of the time I'm using index pages for searching things, but if I wanted to list all functions that somehow use a type, for example, index pages don't help. With type information in the index pages I can just search for a type and my browser would highlight all functions that somehow use the type.
Categories: Offsite Discussion

FP Complete: The new haskell-ide repo

Planet Haskell - Sun, 10/25/2015 - 11:00pm

Recently Alan Zimmerman announced on the haskell-cafe mailing list that there was a new haskell-ide project, with a new Github repository, a mailing list and an IRC channel. Some people have been concerned that this effort is fragmenting existing efforts, including with ide-backend (the open sourced library FP Complete announced earlier this year). I clarified this on Reddit, but wanted to take the opportunity to do so on this blog as well (and, additionally, throw some extra attention on the haskell-ide project).

Alan's announcement did not come in a vacuum; about two weeks ago, he reached out to others for feedback on a potential project. There were some side channel discussions that I was involved in, all of which were very much in favor of (and excited about!) this project. To quote myself from Reddit, we reached the following conclusion:

Both the ghc-mod and ide-backend maintainers have agreed to contribute code to this new repository and then rebase the old repos on this. The reason we're using a new repo instead of modifying one of the existing ones is so that the existing projects experience no disruption during this migration process. If this was a new set of people starting a new project without support from existing projects, I'd agree with you. But Alan's reached out to existing players already, which is an important distinction.

Michael Sloan - the current maintainer of ide-backend and one of the primary developers of both School of Haskell and FP Haskell Center - is already getting involved in this project. It's too early to decide exactly what the future of ide-backend will be relative to haskell-ide, but we're not ruling anything out. Anything from rebasing ide-backend to use haskell-ide internally, all the way to deprecating ide-backend in favor of haskell-ide, is on the table. We'll do whatever makes the most sense to help the Haskell community create great tooling.

Related to this project: a number of people have been following the development of stack-ide. We started that project not realizing how quickly existing tooling (like ghc-mod and hdevtools) would adopt support for Stack, and certainly not expecting this new haskell-ide project to offer a unifying force in the Haskell tooling space. To avoid fragmentation, we're currently holding off on further word on stack-ide, hoping instead that collaboration will help improve existing tooling not just for the Stack use case, but for cabal, cabal sandboxes, and other cases people have been targeting.

Since I'm already discussing IDE stuff, let me publicly give an answer I've given privately to a few people. A number of individuals have asked about the future of the FP Haskell Center codebase, and the possibility of open sourcing it. The summary answer is:

  • Everything related to School of Haskell is being open sourced. Most of that is done already, the rest is just in the last few stages of code cleanup.
  • The current state of the FP Haskell Center code base is difficult to simply give out, since it's based on some superseded technologies. For example, we created it in a world where Docker didn't exist, and have quite a few LXC scripts to make it work. We also have some difficult-to-manage build scripts that could be replaced by Stack. We've cleaned all of this up for School of Haskell, but have not done the same to the FP Haskell Center codebase.
  • As a general policy, we don't like to just drop unsupported code on the community at FP Complete. If there are maintainers that are interested in taking over the current FPHC codebase, we can discuss transferring it over. But simply open sourcing without any support tends not to be a helpful move (instead, it distracts from other, active projects, which we don't want to do).
  • One possibility going forward is that, once the School of Haskell web service is up, running, and stable, a new IDE project could be started that targets that same API. We're not planning on running such a project at FP Complete, but we'd be happy to provide some feedback, and include necessary changes to the SoH service to make it work.

I hope this excites others as much as it excites me: some concerted efforts on improving tooling can hopefully go a long way. A big thank you to Alan for coordinating this effort, and to Michael Sloan for leading the charge from the FP Complete side. I'm optimistic that we'll see some real strides forward in the near future.

Categories: Offsite Blogs

Does Yesod have a console for playing with persistent models?

Haskell on Reddit - Sun, 10/25/2015 - 6:58pm

It's something I'd really like to use. I've found several posts about the possibility, e.g. the Yesod Wish List. But nothing concrete yet.

(I'm gathering this info for a web framework comparison matrix for my next project: )

EDIT: Here's a screenshot of the Rails REPL showing what I'm talking about.

submitted by whither-the-dog
[link] [9 comments]
Categories: Incoming News

Christopher Done: Idle thoughts: More open, more free software

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

I’m a bit busy, these are just some idle thoughts.

I just upgraded my Android OS to some other kind of dessert name and a bunch of stuff changed in a way I had no desire for.

It made me think about the virtues of open source software. I can just go and change it! Free software means benefiting from the work of others without being shackled by them at the same time.

And then about the problems of open source software, which is that only developers-skilled developers-with specific knowledge, are able to approach the codebase of an app they use, update it, and then use that new software in a continuous and smooth way. Everyone else’s hands are effectively tied behind their backs.

So that got me thinking about how software could be more “open” than simply “open source”, if it was inherently more configurable. And also about better migration information from one piece of software to the next.

So I imagined a world in which when I get an update for a piece of software I could see a smart diff, as a regular human, of what the new UI and behaviour looks like, how it changed. This button moved there, changed color. Pressing this button used to exhibit X behaviour, now that behaviour is more complicated, or more limited, to trigger this action, and so on.

I believe that a properly declarative UI library with explicit state modeling, such as in Elm or whatnot, could actually handle a thing like that, but that it would have to be designed from the bottom up like that. And every component would need to have some “mock” meta-data about it, so that the migration tool could say “here’s what the old UI looks like with lorem ipsum data in it and here’s what that same data, migrated, looks like in the new UI” and you could interact with this fake UI on fake data, with no consequences. Or interact with the user’s data in a read-only “fake” way.

You could say: actually, no, I want to configure that this button will stay where it is, that the theme will stay my current dark theme, etc.

You could visualize state changes in the UI such as with the time traveling thing in Elm or React and make new decision trees, or perhaps pick between built-in behaviours.

But one key idea could be that when you update software in a new way, unless you’re removing the ability to do a feature completely (e.g. the server won’t even respond to that RPC call), then you should indicate that, in the intelligent “software diff”: then the user can say, no I still want to use that and now they have a “patched” or “forked” version of the software locally but that the maintainers of the software don’t have to worry about.

Normally configuring software is a thing developers manually hard code into the product. It seems obviously better to make software inherently configurable, from a free software perspective at least (not from a proprietary locked-in perspective).

Of course, you could write code at any time; drop down to that. But if most of the code can be self-describing at least in a high-level “do the thing or that thing” way, this would be far more accessible to general users than code itself which at the moment is magic and certainly beyond my interest to go and patch for the most part.

Categories: Offsite Blogs

Dimitri Sabadie: luminance, episode 0.6: UBO, SSBO, Stackage.

Planet Haskell - Sun, 10/25/2015 - 4:29pm

Up to now, luminance has been lacking two cool features: UBO and SSBO. Both are buffer-backed uniform techniques. That is, a way to pass uniforms to shader stages through buffers.

The latest version of luminance has one of the two features. UBO were added and SSBO will follow for the next version, I guess.

What is UBO?

UBO stands for Uniform Bbuffer Object. Basically, it enables you to create uniform blocks in GLSL in feed them with buffers. Instead of passing values directly to the uniform interface, you just write whatever values you want to to buffers, and then pass the buffer as a source for the uniform block.

Such a technique has a lot of advantages. Among them, you can pass a lot of values. It’s also cool when you want to pass values instances of a structure (in the GLSL source code). You can also use them to share uniforms between several shader programs as well as quickly change all the uniforms to use.

In luminance, you need several things. First thing first, you need… a buffer! More specifically, you need a buffer Region to store values in. However, you cannot use any kind of region. You have to use a region that can hold values that will be fetched from shaders. This is done with a type called UB a. A buffer of UB a can be used as UBO.

Let’s say you want to store colors in a buffer, so that you can use them in your fragment shader. We’ll want three colors to shade a triangle. We need to create the buffer and get the region:

colorBuffer :: Region RW (UB (V3 Float)) <- createBuffer (newRegion 3)

The explicit type is there so that GHC can infer the correct types for the Region. As you can see, nothing fancy, except that we just don’t want a Region RW (V3 Float but Region RW (UB (V3 Float)). Why RW?

Then, we’ll want to store colors in the buffer. Easy peasy:

writeWhole colorBuffer (map UB colors)

colors :: [V3 Float]
colors = [V3 1 0 0,V3 0 1 0,V3 0 0 1] -- red, green, blue

At this point, colorBuffer represents a GPU buffer that holds three colors: red, green and blue. The next part is to get the uniform interface. That part is experimental in terms of exposed interface, but the core idea will remain the same. You’re given a function to build UBO uniforms as you also have a function to build simple and plain uniforms in createProgram:

createProgram shaderList $ \uni uniBlock -> {- … -}

Don’t spend too much time reading the signature of that function. You just have to know that uni is a function that takes Either String Natural – either a uniform’s name or its integral semantic – and gives you mapped U in return and that uniBlock does the same thing, but for uniform blocks instead.

Here’s our vertex shader:

in vec2 co;
out vec4 vertexColor;

// This is the uniform block, called "Colors" and storing three colors
// as an array of three vec3 (RGB).
uniform Colors {
vec3 colors[3];

void main() {
gl_Position = vec4(co, 0., 1.);
vertexColor = vec4(colors[gl_VertexID], 1.);

So we want to get a U a mapped to that "Colors" uniform block. Easy!

(program,colorsU) <- createProgram shaderStages $ \_ uniBlock -> uniBlock "Colors"

And that’s all! The type of colorsU is U (Region rw (UB (V3 Float))). You can then gather colorBuffer and colorsU in a uniform interface to send colorBuffer to colorsU!

You can find the complete sample here.

Finally, you can augment the type you can use UB with by implementing the UniformBlock typeclass. You can derive the Generic typeclass and then use a default instance:

data MyType = {- … -} deriving (Generic)

instance UniformBlock MyTpe -- we’re good to go with buffer of MyType!luminance, luminance-samples and Stackage

I added luminance and luminance-samples into Stackage. You can then find them in the nightly snapshots and the future LTS ones.

What’s next?

I plan to add stencil support for the framebuffer, because it’s missing and people might like it included. I will of course add support for *SSBO** as soon as I can. I also need to work on cheddar but that project is complex and I’m still stuck with design decisions.

Thanks for reading my and for your feedback. Have you great week!

Categories: Offsite Blogs

Glib- build failure: multiple definition of `__debugbreak' (ghc-7.11.20151024)

haskell-cafe - Sun, 10/25/2015 - 3:17pm
In my latest attempt to finally build the gtk3 package with ghc-head 'ghc-master' (7.11.20151024) for a current project under windows x64 using the latest msys2-version and its supplied gtk3 libraries (mingw64/mingw-w64-x86_64-gtk3 3.18.2-1) I encountered this cryptical (linking) error. (See complete log for command './Setup build -v3' attached) I should add that I'm rather a beginner with regards to the Haskell language and its package distribution system cabal. Thus all thoughts, ideas and suggestions how to fix this problem are welcome. Best regards Burkhard complete building response in msys2-shell using the mingw64 script: $ ./Setup build -v3 Component build order: library creating dist\build creating dist\build\autogen Building glib- Environment: [("","C:=C:\\Windows\\System32"),("ACLOCAL_PATH","C:\\MSYS2\\mingw64\\share\\aclocal;C:\\MSYS2\\usr\\share\\aclocal"),("ALLUSERSPROFILE","C:\\ProgramData"),("APPDATA","C:\\Users\\PC-08\\AppData\\Roaming"),("CHECKDEF","C:\\Applications\\w
Categories: Offsite Discussion

Avoiding Dependency loops

haskell-cafe - Sun, 10/25/2015 - 9:36am
Hello all, I just split up a program I'm working on into several source files and ran into the following difficulty: module Process implements Process which has a field Runner. Runner is a basically a function which alters a 'System' state. So Process needs Runner, Runner needs System and thus Process needs System. module System implements among others a collection of Processes (because Processes can alter their states). So System needs Process. Eh voila, I have a loop. What I did was to leave the type of the Runner unspecified in Process, i.e. I now have (Process r) where r is the type of the Runner. Thus Process no longer needs to know about System. This does work, but it feels strange and I'm a bit worried that this is an indication for a design flaw, but I cannot see it.
Categories: Offsite Discussion

Projectional editing: Separating a program's ASTfrom its presentation

haskell-cafe - Sun, 10/25/2015 - 5:08am
These ideas were touched on in a previous thread [1]. Our work would be easier if, as data, we separated a program's AST from its layout. If, for instance, the order in which a library's functions are presented on the page were stored as a "projection", separate from the AST that defined those functions, then one could reorder the functions without obscuring the history of changes to anything that was "moved". I assume I am not alone in making a lot of edits aimed solely at allowing me to read or traverse the code faster? Those within-function changes of presentation, like across-function changes of order, obscure the record of functional (as opposed to cosmetic) changes. They don't have to. Moreover, if projections and the AST were separate data, one could use contradictory hierarchiies|projections|layouts for the same data. One projection might group functions by their common purpose (an "is-tree"), while another grouped them by priority to the reader-rewriter (a "do-tree"). Given current technology,
Categories: Offsite Discussion

ICFP 2016 Call for Workshop and Co-located Event Proposals

General haskell list - Sat, 10/24/2015 - 12:31am
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;CALL FOR WORKSHOP AND CO-LOCATED EVENT PROPOSALS &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ICFP 2016 &nbsp;21st ACM SIGPLAN International Conference on Functional Programming &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;September 18-24, 2016 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Nara, Japan &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; The 21st ACM SIGPLAN International Conference on Functional Programming will be held in Nara, Japan on September 18-24, 2016. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for workshops (and other co-located events, such as tutorials) to be affiliated with ICFP 2016 and sponsored by SIGPLAN. These events should
Categories: Incoming News

New gtk2hs 0.12.4 release

gtk2hs - Wed, 11/21/2012 - 12:56pm

Thanks to John Lato and Duncan Coutts for the latest bugfix release! The latest packages should be buildable on GHC 7.6, and the cairo package should behave a bit nicer in ghci on Windows. Thanks to all!


Categories: Incoming News