News aggregator

Trouble with forkProcess

haskell-cafe - Sat, 02/21/2015 - 2:58am
Hi folks, I’d love to get a sense of the prevailing wisdom with respect to forkProcess from System.Posix.Process. I’m building a multithreaded (STM) application with potentially many threads simultaneously reading and writing to pieces of (an otherwise rather large) shared state. Occasionally I would like to record a whole snapshot of that state, and it seems to me a natural way to accomplish this is to fork a process (eliminating all the other threads) and perform a read-only dump of the state. This dump can be time-consuming, which is why I’d rather not have contention with other threads that may be trying to modify the state while I’m dumping. My experience with forkProcess so far is that sometimes it works brilliantly, and other times it just deadlocks. I’m at a loss to understand what the problem is, but the deadlock seems to occur before the new process gets any control -- certainly before it has started to access any of the shared state. I’m aware of the giant warning in the forkProces
Categories: Offsite Discussion


libraries list - Sat, 02/21/2015 - 2:03am
We are using this function from base in Darcs in a way that causes trouble: the returned file handle is closed immediately and only the filename is passed on. Then the file gets re-opened and closed again and some time later deleted. If openBinaryTempFile is used in this way a few times in a row, it returns the same file name every time. I tested this with a small test program. My question: is openBinaryTempFile supposed to behave like that (if used in this way)? I am testing this on an ubuntu trusty with ghc-7.6.3, meaning base- Has the function been changed in later versions? Cheers Ben
Categories: Offsite Discussion

Is there any simple explanation (or, better, implementation) of type inference for the simply typed lambda calculus in Haskell?

Haskell on Reddit - Fri, 02/20/2015 - 9:36pm

I've been looking though Google for quite some time but couldn't find anything convincing, other than huge papers, and an 8-liner implementation on Curry, which used builtin unification. Anything simpler would be highly appreciated.

submitted by SrPeixinho
[link] [4 comments]
Categories: Incoming News

FLTK GUI bindings - Alpha release

Haskell on Reddit - Fri, 02/20/2015 - 8:19pm

I'm pleased to announce the alpha release of Haskell bindings to the FLTK GUI library.

On Linux and Mac this package and FLTK 1.3.3 should install pretty smoothly.

The library covers about 80+% of API and has 60+ widgets that can be used transparently from Haskell.

You can read more about the motivation behind the library, installation instructions and quick start documentation here.

The package also comes with 14 demos to show you how to get started.

There still isn't any support for Windows because I don't have access to a Windows machine, and don't have any experience with the Windows C/C++ build tools. The code itself should be fully portable. I could use some help here.

Please report any issues on the Github page.

Hope you enjoy and I'd love any feedback on the install and development process.

submitted by deech
[link] [6 comments]
Categories: Incoming News

Keegan McAllister: Turing tarpits in Rust's macro system

Planet Haskell - Fri, 02/20/2015 - 7:55pm
Bitwise Cyclic Tag is an extremely simple automaton slash programming language. BCT uses a program string and a data string, each made of bits. The program string is interpreted as if it were infinite, by looping back around to the first bit.

The program consists of commands executed in order. There is a single one-bit command:

0: Delete the left-most data bit.

and a single two-bit command:

1 x: If the left-most data bit is 1, copy bit x to the right of the data string.

We halt if ever the data string is empty.

Remarkably, this is enough to do universal computation. Implementing it in Rust's macro system gives a proof (probably not the first one) that Rust's macro system is Turing-complete, aside from the recursion limit imposed by the compiler.


macro_rules! bct {
// cmd 0: d ... => ...
(0, $($ps:tt),* ; $_d:tt)
=> (bct!($($ps),*, 0 ; ));
(0, $($ps:tt),* ; $_d:tt, $($ds:tt),*)
=> (bct!($($ps),*, 0 ; $($ds),*));

// cmd 1p: 1 ... => 1 ... p
(1, $p:tt, $($ps:tt),* ; 1)
=> (bct!($($ps),*, 1, $p ; 1, $p));
(1, $p:tt, $($ps:tt),* ; 1, $($ds:tt),*)
=> (bct!($($ps),*, 1, $p ; 1, $($ds),*, $p));

// cmd 1p: 0 ... => 0 ...
(1, $p:tt, $($ps:tt),* ; $($ds:tt),*)
=> (bct!($($ps),*, 1, $p ; $($ds),*));

// halt on empty data string
( $($ps:tt),* ; )
=> (());

fn main() {
bct!(0, 0, 1, 1, 1 ; 1, 0, 1);

This produces the following compiler output:

bct! { 0 , 0 , 1 , 1 , 1 ; 1 , 0 , 1 }
bct! { 0 , 1 , 1 , 1 , 0 ; 0 , 1 }
bct! { 1 , 1 , 1 , 0 , 0 ; 1 }
bct! { 1 , 0 , 0 , 1 , 1 ; 1 , 1 }
bct! { 0 , 1 , 1 , 1 , 0 ; 1 , 1 , 0 }
bct! { 1 , 1 , 1 , 0 , 0 ; 1 , 0 }
bct! { 1 , 0 , 0 , 1 , 1 ; 1 , 0 , 1 }
bct! { 0 , 1 , 1 , 1 , 0 ; 1 , 0 , 1 , 0 }
bct! { 1 , 1 , 1 , 0 , 0 ; 0 , 1 , 0 }
bct! { 1 , 0 , 0 , 1 , 1 ; 0 , 1 , 0 }
bct! { 0 , 1 , 1 , 1 , 0 ; 0 , 1 , 0 }
bct! { 1 , 1 , 1 , 0 , 0 ; 1 , 0 }
bct! { 1 , 0 , 0 , 1 , 1 ; 1 , 0 , 1 }
bct! { 0 , 1 , 1 , 1 , 0 ; 1 , 0 , 1 , 0 }
bct! { 1 , 1 , 1 , 0 , 0 ; 0 , 1 , 0 }
bct! { 1 , 0 , 0 , 1 , 1 ; 0 , 1 , 0 }
bct! { 0 , 1 , 1 , 1 , 0 ; 0 , 1 , 0 }
... 19:45 error: recursion limit reached while expanding the macro `bct` => (bct!($($ps),*, 1, $p ; $($ds),*));

You can try it online, as well.

Notes about the macro

I would much rather drop the commas and write

// cmd 0: d ... => ...
(0 $($ps:tt)* ; $_d:tt $($ds:tt)*)
=> (bct!($($ps)* 0 ; $($ds)*));

// cmd 1p: 1 ... => 1 ... p
(1 $p:tt $($ps:tt)* ; 1 $($ds:tt)*)
=> (bct!($($ps)* 1 $p ; 1 $($ds)* $p));

// cmd 1p: 0 ... => 0 ...
(1 $p:tt $($ps:tt)* ; $($ds:tt)*)
=> (bct!($($ps)* 1 $p ; $($ds)*));

but this runs into the macro future-proofing rules.

If we're required to have commas, then it's at least nice to handle them uniformly, e.g.

// cmd 0: d ... => ...
(0 $(, $ps:tt)* ; $_d:tt $(, $ds:tt)*)
=> (bct!($($ps),*, 0 ; $($ds),*));

// cmd 1p: 1 ... => 1 ... p
(1, $p:tt $(, $ps:tt)* ; $($ds:tt),*)
=> (bct!($($ps),*, 1, $p ; 1 $(, $ds)*, $p));

// cmd 1p: 0 ... => 0 ...
(1, $p:tt $(, $ps:tt)* ; $($ds:tt),*)
=> (bct!($($ps),*, 1, $p ; $($ds),*));

But this too is disallowed. An $x:tt variable cannot be followed by a repetition $(...)*, even though it's (I believe) harmless. There is an open RFC about this issue. For now I have to handle the "one" and "more than one" cases separately, which is annoying.

In general, I don't think macro_rules! is a good language for arbitrary computation. This experiment shows the hassle involved in implementing one of the simplest known "arbitrary computations". Rather, macro_rules! is good at expressing patterns of code reuse that don't require elaborate compile-time processing. It does so in a way that's declarative, hygienic, and high-level.

However, there is a big middle ground of non-elaborate, but non-trivial computations. macro_rules! is hardly ideal for that, but procedural macros have problems of their own. Indeed, the bct! macro is an extreme case of a pattern I've found useful in the real world. The idea is that every recursive invocation of a macro gives you another opportunity to pattern-match the arguments. Some of html5ever's macrosdo this, for example.

Categories: Offsite Blogs

How to best implement Euler's method?

Haskell on Reddit - Fri, 02/20/2015 - 5:08pm

I am using Euler's method to solve the simple ODE for nuclear decay (see this PDF I just found with google if interested in the math). The math is fine, and I've implemented it in Haskell using recursion to the best of my knowledge, but it is slow.

What is the proper way to do something like this in a purely functional manner? I want to use the results from the previous calculations when I generate list, but I don't know how. I am a complete Haskell noob, so please enlighten me on how I can improve this program. Thanks!

module Main where --import Graphics.Gnuplot.Simple dt = 0.01 -- Timestep tau = 0.05 -- Decay constant n0 = 1000 -- Initial number of particles main = do --plotList [] list print list list :: [(Double, Double)] list = [(num t, t) | t <- [0.0, dt..tau*4]] num :: Double -> Double num t | t > 0 = num (t - dt) - dt / tau * num (t - dt) | otherwise = n0 submitted by 0not
[link] [6 comments]
Categories: Incoming News

Robert Harper: Structure and Efficiency of Computer Programs

Planet Haskell - Fri, 02/20/2015 - 4:37pm

For decades my colleague, Guy Blelloch, and I have promoted a grand synthesis of the two “theories” of computer science, combinatorial theory and logical theory.  It is only a small exaggeration to say that these two schools of thought work in isolation.  The combinatorial theorists concern themselves with efficiency, based on hypothetical translations of high-level algorithms to low-level machines, and have no useful theory of composition, the most important tool for developing large software systems.  Logical theorists concern themselves with composition, emphasizing the analysis of the properties of components of systems and how those components are combined; the heart of logic is a theory of composition (entailment).  But relatively scant attention is paid to efficiency, and, to a distressingly large extent, the situation is worsening, and not improving.

Guy and I have argued, through our separate and joint work, for the applicability of PL ideas to algorithms design, leading. for example, to the concept of adaptive programming that Umut Acar has pursued aggressively over the last dozen years.  And we have argued for the importance of cost analysis, for various measures of cost, at the level of the code that one actually writes, and not how it is compiled.  Last spring, prompted by discussions with Anindya Banerjee at NSF in the winter of 2014, I decided to write a position paper on the topic, outlining the scientific opportunities and challenges that would arise in an attempt to unify the two, disparate theories of computing.  I circulated the first draft privately in May, and revised it in July to prepare for a conference call among algorithms and PL researchers (sponsored by NSF) to find common ground and isolate key technical challenges to achieving its goals.

There are serious obstacles to be overcome if a grand synthesis of the “two theories” is to be achieved.  The first step is to get the right people together to discuss the issues and to formulate a unified vision of what are the core problems, and what are promising directions for short- and long-term research.  The position paper is not a proposal for funding, but is rather a proposal for a meeting designed to bring together two largely (but not entirely) disparate communities.  In summer of 2014 NSF hosted a three-hour long conference call among a number of researchers in both areas with a view towards hosting a workshop proposal in the near future.  Please keep an eye out for future developments.

I am grateful to Anindya Banerjee at NSF for initiating the discussion last winter that led to the paper and discussion, and I am grateful to Swarat Chaudhuri for his helpful comments on the proposal.

[Update: word smithing, corrections, updating, removed discussion of cost models for fuller treatment later, fixed incoherence after revision.]

Filed under: Research Tagged: algorithms, programming languages, research
Categories: Offsite Blogs

Austin Seipp: The New Haskell Homepage

Planet Haskell - Fri, 02/20/2015 - 2:55pm

Roughly 3/4 of a year after Chris Done first proposed his redesign, we finally went live with the new homepage.

Much of the intermediate time was spent on cleanup of the introductory text, as well as adding features and tweaking designs. There was also a very length process of setting everything up to ensure that the "try it" feature could be deployed and well supported. Finally, we had to do all the work to ensure that both the wiki remained hosted well somewhere else with proper rewrite rules, and also that the non-wiki content hosted under (things like /ghc, /platform, /hoogle, etc) continued to work. Some of the more publicly visible elements of this are the move of mailinglist hosting to and of the wiki content to

When we did finally go live, we got great feedback on reddit and made #1 on hacker news.

There were also a lot of things we missed, and which those threads pointed out -- in particular we didn't pay enough attention to the content of various pages. The "documentation" and "community" section needed lots of cleanup and expansion. Furthermore, the "downloads" page didn't point to the platform. Whoops! (It is to be noted that recommendation of the platform or not is an issue of some discussion now, for example on this active reddit thread. )

We think that we have fixed most of the issues raised. But there are still issues! The code sample for primes doesn't work in the repl. We have an active github ticket discussing the best way to fix this -- either change the sample, change the repl, or both. This is one of a number of issues under discussion on the github tracker.

We still want feedback, we still want patches, and there's still plenty to be made more awesome. For example: should we have some sort of integrated search? How? Where? The github infrastructure makes taking patches and tracking these issues easy. The repo now has 27 contributors, and we're look forward to more.

One balance that has been tricky to strike has been in making the site maximally useful for new users just looking to learn and explore Haskell, while also providing access to the wide range of resources and entry points that the old wiki did. One advantage that we have now is that the wiki is still around, and is still great. Freed from needing to also serve as a default haskell landing page, the wiki can hopefully grow to be an even better resource. It needs volunteers to chip in and curate the content. And ideally it needs a new front page that highlights the things that you _won't_ find on the main homepage, instead of the things you now can. One place we could use more help is in wiki admins, if anyone wants to volunteer. We need people to curate the news and events sections, to fight spam, to manage plugins and investigate adding new features, to update and clean up the stylesheets, and to manage new user accounts. If you're interested, please get in touch at admin@h.o.

All the resources we have today are the result of our open-source culture, that believes in equal parts in education, innovation, and sharing. They stem from people who enjoy Haskell wanting to contribute back to others -- wanting to make more accessible the knowledge and tools they've struggled to master, and wanting to help us make even better and more powerful tools.

There's always more infrastructure work to be done, and there are always more ways to get involved. In a forthcoming blog, I'll write further about some of the other pressing issues we hope to tackle, and where interested parties can chip in.

Categories: Offsite Blogs

A public thank-you for the `lucid` package!

Haskell on Reddit - Fri, 02/20/2015 - 11:40am

I just made a 42 slide html presentation about lambda calculus, with interactive parts, without writing anything else than pure Haskell. Before lucid, this would have been just painful, but now, it was easier to it do this way than by using latex+beamer or even pandoc.

Well Done Chris.

submitted by aleator
[link] [18 comments]
Categories: Incoming News

type checker plugin success depends on whether an expression is manually inlined

glasgow-user - Fri, 02/20/2015 - 4:48am
Hello list, The following file compiles with my plugin. It makes a data family HList have role representational in a way that I believe is safe: I expect the highlighted line to be acceptable. However, it seems that the plugin never sees anything from line 19, when I uncomment it. Is there something I can do to make that L19 work? Is this a known or intentional limitation of type checker plugins? Thanks, Adam
Categories: Offsite Discussion

Generating modules with data

Haskell on Reddit - Fri, 02/20/2015 - 4:38am
Categories: Incoming News