News aggregator

What's the right way to name packages and modules?

Haskell on Reddit - Mon, 09/15/2014 - 8:52am

I have a package of database functionality called library which was developed internally at corporation. The current package name is corporation-library and the module hierarchy starts at Corporation.Library.

At some point this will be released on Hackage, and I am wondering what to do about naming. Personally I like the namespacing effect and the credit-giving effect of keeping corporation in the name of the package and modules, but I realise this may seem a bit odd to the community.

The other alternative is

  • rename the package to just library (this doesn't clash this any existing Haskell package or indeed any package from any programming language)
  • rename the module hierarchy to Library or Database.Library

Thoughts?

submitted by tomejaguar
[link] [13 comments]
Categories: Incoming News

The GHC Team: GHC Weekly News - 2014/09/15

Planet Haskell - Mon, 09/15/2014 - 7:47am

Hi *,

Here's a new thing: Blog posts! That's right. A while back, we started a new set of emails on the developers list containing weekly updates, from GHC HQ. But we eventually decided it should be more broad and encompass the work GHC sees as a project - including all the things our contributors do.

So now it's the weekly GHC news - and we (or, well, I) have decided to blogify the weekly emails!

So without further adieu, here's the current recap. The original mailing list copy is available ​here.

  • As Gabor mentioned on the list earlier today, I (Austin) accidentally broke the Windows build. Sorry. :( We really need to get Phab building Windows too ASAP... I'm working on a fix this morning.
  • I sent out the HCAR draft this morning. Please edit it! I think we have a few weeks of lead time however, so we're not in a rush like last time. But I will send reminders. :)
  • The server migration for ghc.haskell.org seems to have gone pretty smoothly in the past week. It's had plenty of traffic so far. The full migration is still ongoing and I want to complete it this week.
  • I've finished reorganizing some of the Git and Repository pages after some discussion. We now have the Repositories[1] page, linked to on the left side, which details some notes on the repositories we use, and links to other various pages. I'm thinking of replacing this side-bar "root" with a link to the main Git[2] page, perhaps.
  • Miscellaneous: ghc.haskell.org and phabricator.haskell.org now sets the Strict-Transport-Security header. This just means you always use SSL now when you visit those pages (so you can't be connection-hijacked via a 503 redirect).
  • GHC works on Wine apparently for all you Linux users - thanks Mikolaj![3]
  • Jan had some questions about infrastructure which I just followed up on this morning. In particular: does anyone feel strongly about his first question?[4]
  • Herbert committed the first part of the Traversable/Foldable changes, by moving the typeclasses to Prelude. This is part of an ongoing series of patches. Things like adding Bifunctor will finally come after this.[5]

Also, added bonus: we'll start including some of the tickets we closed this week.

Closed tickets for the past week include: #9585, #9545, #9581, #6086, #9558, and #3658.

Please let me know if you have any questions.

[1] ​https://ghc.haskell.org/trac/ghc/wiki/Repositories
[2] ​https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git
[3] ​https://www.haskell.org/pipermail/ghc-devs/2014-September/006283.html
[4] ​https://www.haskell.org/pipermail/ghc-devs/2014-September/006275.html
[5] ​https://phabricator.haskell.org/D209

Categories: Offsite Blogs

How should I go about making a function more elegant?

Haskell on Reddit - Mon, 09/15/2014 - 2:38am

Say I have this idea which seems pretty simple in my head. But then when implementing it in a function, I realize this is needed, and that is needed, and now when I'm done, the function works, but it is really ugly. Too ugly for what is really a simple thing.

Anybody had this problem before? Any advice on how you would go about fixing the code smell?

submitted by ninklo
[link] [12 comments]
Categories: Incoming News

Simulating trade system with FRP (or pipes or conduit)

Haskell on Reddit - Sun, 09/14/2014 - 11:54pm

I would like to simulate a system of the following nature:

The system receives "ticks" at an unpredictable interval (depends on volume, etc.). Ticks serve two main purposes: the first is that ticks will be converted to "candles" [1]. There would be candles at various frequencies: at least 1,5,15,30 minute, 1,4,8 hour, 1 day, 1 week and 1 month. There would be signal generators that look at one or more of these candles to produce trading signals. The second purpose of the ticks would be when a signal is generated and the system issues an order, the "fill" price would come from a tick received after those used to generate the signal (e.g. if tick 1,000 caused ticks to be produced for 1,5,15 and 30 minute candles, and some of those candles triggered trading signals, when the buy/sell order comes the "fill" will be from a tick >1,000).

In thinking about how to implement such a system, it seemed to me that it might be a fit for FRP. Ticks would just be a normal "event" (not sure if my terminology will be correct), 1 minute candle would listen to this event, collect the seen high/low values and record the first value seen and the last of its timeframe before generating a 1 minute candle event. The 5 minute event would listen to the 1 minute event and generate its own event after 5 received minute candles, etc. This way we only need to hang onto enough ticks to generate a single minute event.

With such a design, the "order fill" part of the code could theoretically listen to the tick event (so minute and order fill are listening to that event) but in that case would it be guaranteed that by the time a trade signal was generated and order created that the tick seen by the order fill system will be one that came after the ones seen by the candles?

Also, I would be interested if people believe such a system would be better modelled in Pipes or Conduit and why.

[1] Candle being a high/low/open/close measurement over the frequency specified. For example 1m { 10/2/8/4 } would be a one minute candle where the first tick seen had a value of 8, the last seen was 4, the highest seen was 10 and the lowest 2.

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

Control.Monad.Error deprecated?

haskell-cafe - Sun, 09/14/2014 - 8:40pm
Hello everyone, I just discovered that Control.Monad.Error [1] has recently become deprecated in favor of Control.Monad.Except [2], and I am curious about what motivated the change. Can anyone explain? Thanks, Karl 1: http://hackage.haskell.org/package/mtl-2.2.1/docs/Control-Monad-Error.html 2: http://hackage.haskell.org/package/mtl-2.2.1/docs/Control-Monad-Except.html
Categories: Offsite Discussion

Mike Izbicki: Comparing AVL Trees in C++ and Haskell

Planet Haskell - Sun, 09/14/2014 - 6:00pm
Comparing AVL Trees in C++ and Haskell posted on 2014-09-15 by Dat Do

This post compares the runtimes of AVL tree operations in C++ vs Haskell. In particular, we insert 713,000 strings from a file into an AVL Tree. This is a \(O(n \log n)\) operation. But we want to investigate what the constant factor looks like in different situations.

Experimental setup: All the code for these tests is available in the github repository. The C++ AVL tree was created in a data structures course that I took recently and the Haskell AVL tree is from the Haskell library Data.Tree.AVL. Additionally, the Haskell code stores the strings as ByteStrings because they are much more efficient than the notoriously slow String. To see how the runtime is affected by files of different sizes, the file was first partitioned into 10 segments. The first segment has 71,300 words, the second 71,300 * 2 words, and so on. Both the C++ and Haskell programs were compiled with the -O2 flag for optimization. The test on each segment is the average runtime of three separate runs.

Here’s the results:

C++vHaskell

C++ is a bit faster than Haskell on the last partition for this test.

I guess this is because Haskell operates on immutable data. Every time a new element is to be inserted into the Haskell AVL tree, new parent nodes must be created because the old parent nodes cannot be changed. This creates quite a bit of overhead. C++ on the other hand, does have mutable data and can simply change the node that a parent node is pointing to. This is faster than making a whole new copy like the Haskell code does.

Is there an easy way to speed up our Haskell code?

There is a Haskell library called parallel that makes parallel computations really convenient. We’ll try to speed up our program with this library.

You might think that it is unfair to compare multithreaded Haskell against C++ that is not multithreaded. And you’re absolutely right! But let’s be honest, manually working with pthreads in C++ is quite the headache, but parallism in Haskell is super easy.

Before we look at the results, let’s look at the parallelized code. What we do is create four trees each with a portion of the set of strings. Then, we call par on the trees so that the code is parallelized. Afterwards, we union the trees to make them a single tree. Finally, we call deepseq so that the code is evaluated.

{-# LANGUAGE TemplateHaskell #-} import Control.DeepSeq.TH import Control.Concurrent import Data.Tree.AVL as A import Data.COrdering import System.CPUTime import qualified Data.ByteString.Char8 as B import Control.DeepSeq import Data.List.Split import System.Environment import Control.Parallel $(deriveNFData ''AVL) -- Inserts elements from list into AVL tree load :: AVL B.ByteString -> [B.ByteString] -> AVL B.ByteString load t [] = t load t (x:xs) = A.push (fstCC x) x (load t xs) main = do args <- getArgs contents <- fmap B.lines $ B.readFile $ args !! 0 let l = splitEvery (length contents `div` 4) contents deepseq contents $ deepseq l $ return () start <- getCPUTime -- Loading the tree with the subpartitions let t1 = load empty $ l !! 0 let t2 = load empty $ l !! 1 let t3 = load empty $ l !! 2 let t4 = load empty $ l !! 3 let p = par t1 $ par t2 $ par t3 t4 -- Calling union to combine the trees let b = union fstCC t1 t2 let t = union fstCC t3 t4 let bt = union fstCC b t let bt' = par b $ par t bt deepseq p $ deepseq bt' $ return () end <- getCPUTime n <- getNumCapabilities let diff = ((fromIntegral (end-start)) / (10^12) / fromIntegral n) putStrLn $ show diff

Great, so now that the Haskell code has been parallelized, we can compile and run the program again to see the difference. To compile for parallelism, we must use some special flags.

ghc –O2 filename -rtsopts –threaded

And to run the program (-N4 refers to the number of cores).

./filename +RTS –N4

C++vHaskell4

Haskell now gets better runtimes than C++.

Now that we know Haskell is capable of increasing its speeds through parallelism, it would be interesting to see how the runtime is affected by the degree of parallelism.

According to Amdahl’s law, a program that is 100% parallelized will see a proportional speed up based on the number of threads of execution. For example, if a program that is 100% parallelized takes 2 seconds to run on 1 thread, then it should take 1 second to run using 2 threads. The code used for our test, however, is not 100% parallelized since there a union operation performed at the end to combine the trees created by the separate threads. The union of the trees is a \(O(n)\) operation while the insertion of the strings into the AVL tree is a \(O\left(\frac{n \log n }{p}\right)\) operation, where \(p\) is the number of threads. Therefore, the runtime for our test should be

\[O\left(\frac{n\log{n}}{p} + n\right)\]

Here is a graph showing the runtime of the operation on the largest set (713,000 strings) across increasing levels of parallelism.

HaskellParallelization

Taking a look at the results, we can see that the improvement in runtime does not fit the 100% parallelized theoretical model, but does follow it to some extent. Rather than the 2 core runtime being 50% of the 1 core runtime, the 2 core runtime is 56% of the 1 core runtime, with decreasing efficiency as the number of cores increases. Though, it is clear that there are significant improvements in speed through the use of more processor cores and that parallelism is an easy way to get better runtime speeds with little effort.

Categories: Offsite Blogs

Philip Wadler: The British Biased Corporation

Planet Haskell - Sun, 09/14/2014 - 4:01pm
Scandalous! Nick Robinson asks Alex Salmond a question, and Salmond takes seven minutes to answer in detail.

<iframe allowfullscreen="" frameborder="0" height="315" src="http://www.youtube.com/embed/rHmLb-RIbrM" width="560"></iframe>

On the evening news, Nick Robinson summarises Salmond's answer in a few seconds as 'He didn't answer'.

<iframe allowfullscreen="" frameborder="0" height="259" src="http://www.youtube.com/embed/enrdDaf3uss" width="460"></iframe>
(Above spotted via Arc of Prosperity.)

And today, this.
I used to be a supporter of the BBC, but it's getting harder and harder to justify.
Categories: Offsite Blogs

Type union

haskell-cafe - Sun, 09/14/2014 - 3:32pm
Hello! I am trying to create type safe boolean formula representation. Main operation is substion of particular value, to get another formula, and function that accept formula to calculate it's value. So target is: a = Conjunction (Var X) (Var Y) is 2 variable formula value (apply (X, True) . apply (Y, True) $ a) -- True and neither value a apply (X, True) . apply (X, False) $ a typechecks. How can I archive it? class Union a b c instance (a ~ b) => Union a b b instance Union a b (a, b) data P = P deriving Show data Q = Q deriving Show class (Show a) => Variable a instance Variable P instance Variable Q data Formula t where Prop :: (Variable b) => b -> Formula b Conjunction :: (Union t1 t2 t3) => Formula t1 -> Formula t2 -> Formula t3 deriving instance Show (Formula t) main = print (Conjunction (Prop P) (Prop Q) :: Int) This complains on ambitious t3. Attempt by typefamilies fails, since type family Union t1 t2 :: * data Void type instance Union a a = a type instance Uni
Categories: Offsite Discussion

Question on Parsing Haskell Subset

Haskell on Reddit - Sun, 09/14/2014 - 2:34pm

I was curious if someone could explain or point me at the relevant code to understand how GHC handles parsing for custom operator (i.e. infixl 1 >>=) declarations. I'm interested in parsing a small Haskell subset using Happy ( ignore haskell-src-exts for the moment ) and I find I can't unambiguously parse operators without statefully holding a context of the user-defined symbols and their precedences as I parse through a module.

Is there some trick to doing this with Happy and/or does GHC rewrite and shift expressions after it parses everything and has all the information available.

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

Philip Wadler: Krugman vs. Stiglitz, now with added Stiglitz

Planet Haskell - Sun, 09/14/2014 - 12:13pm
My last post quoted Joe Stiglitz, indirectly, to refute Paul Krugman's fear mongering. Now the man himself has spoken in the Sunday Herald.As Scotland contemplates independence, some, such as Paul Krugman, have questioned the "economics".

Would Scotland, going it alone, risk a decline in standards of living or a fall in GDP? There are, to be sure, risks in any course of action: should Scotland stay in the UK, and the UK leave the EU, the downside risks are, by almost any account, significantly greater. If Scotland stays in the UK, and the UK continues in its policies which have resulted in growing inequality, even if GDP were slightly larger, the standards of living of most Scots could fall.

Cutbacks in UK public support to education and health could force Scotland to face a set of unpalatable choices - even with Scotland having considerable discretion over what it spends its money on.

But there is, in fact, little basis for any of the forms of fear-mongering that have been advanced. Krugman, for instance, suggests that there are significant economies of scale: a small economy is likely, he seems to suggest, not to do well. But an independent Scotland will still be part of Europe, and the great success of the EU is the creation of a large economic zone.

Besides, small political entities, like Sweden, Singapore, and Hong Kong have prospered, while much larger entities have not. By an order of magnitude, far more important is pursuit of the right policies.

Another example of a non-issue is the currency. There are many currency arrangements that would work. Scotland could continue using sterling - with or without England's consent.

Because the economies of England and Scotland are so similar, a common currency is likely to work far better than the euro - even without shared fiscal policy. But many small countries have managed to have a currency of their own - floating, pegged, or "managed."
Categories: Offsite Blogs

Philip Wadler: Dinna fash yersel — Scotland will dae juist fine!

Planet Haskell - Sun, 09/14/2014 - 12:13pm
One relentless lie behind 'No' is that Scotland is too wee to make it on its own, counterexamples such as Denmark, Sweden, Singapore, and Hong Kong being conveniently ignored. May this post from Thomas Widmann, a Dane residing in Scotland, help to dispel the disinformation. 
Pick a random person from somewhere on this planet. Ask them to name an alcoholic drink from Scotland, and it’s very likely they’ll reply “Whisky”. Ask them to name one from Denmark, and they’ll probably be tongue-tied. (They could answer “Gammel Dansk” or “Akvavit”, but they’re just not nearly as famous as whisky.)

Now repeat the exercise, but ask about a food item. Again, it’s likely they’ll have heard of haggis but that they’ll be struggling to name anything from Denmark.

Now try a musical instrument. Bagpipes and … sorry, cannot think of a Danish one.

A sport? Scotland has golf, of course. Denmark can perhaps claim ownership of handball, but it’s not associated with Denmark in the way that golf makes everybody think of Scotland.

A piece of clothing? Everybody knows the kilt, but I’d be very surprised if anybody can name one from Denmark.

A monster? Everybody knows what’s lurking in Loch Ness, but is there anything scary in Denmark?

The only category where Denmark perhaps wins is toys, where Lego surely is more famous than anything from Scotland (but many people don’t know Lego is from Denmark).

Denmark is also well-known for butter and bacon, of course, but these aren’t Danish in origin or strongly associated with Denmark in people’s minds.

Several famous writers and philosophers were Danish (e.g., Hans Christian Andersen and Søren Kierkegaard), but Scotland can arguably list more names of the same calibre, and the Scottish ones wrote in English, which makes them much more accessible to the outside world.

Scottish universities are also ranked better than the Danish ones in recent World rankings.

Finally, Scotland has lots of oil and wind, water and waves. Denmark has some, but not nearly as much, and most other countries have less than Denmark.

Because of all of this, I don’t worry about the details when it comes to Scottish independence. If Denmark can be one of the richest countries on the planet, of course Scotland can be one too.

Yes, there might be a few tough years while the rUK are in a huff and before everything has been sorted out. And of course there will be occasional crises in the future, like in any other country.

However, unless you subscribe to the school that Denmark and other small countries like Norway and Switzerland are complete failures because they don’t have nuclear weapons and a permanent seat on the UN’s Security Council, there’s simply no reason to assume Scotland won’t do exceptionally well as an independent country in the longer term.

So I’m not worried. Of course there are many details to sort out, but at the end of the day everything will be fine. Scotland will be a hugely successful independent country. Dinna fash yersel!
Categories: Offsite Blogs

Inferring Algebraic Effects

Haskell on Reddit - Sun, 09/14/2014 - 10:12am
Categories: Incoming News

Did hackage stop building packages?

Haskell on Reddit - Sun, 09/14/2014 - 5:31am

It seems as if the last package with haddock documentation is effect-monad-0.6. (Thu Sep 11 15:40:06 UTC 2014). Everything uploaded since then has not been built apparently. Is this a temporary condition?

submitted by 45g
[link] [10 comments]
Categories: Incoming News

Bind (>>=) in haskell, why is it the same as SelectMany in Linq (C#) ?

Haskell on Reddit - Sun, 09/14/2014 - 4:35am

Hi everyone, when I first learned about Monads in Haskell, I was told that the bind operator is the same as SelectMany in Linq, but I still can't wrap my mind around it ? Why is it not simply equivalent to Select ?

Thank you.

submitted by binge_learner
[link] [13 comments]
Categories: Incoming News

An operational and axiomatic semantics for non-determinism and sequence points in C

Lambda the Ultimate - Sun, 09/14/2014 - 3:36am

In a recent LtU discussion, naasking comments that "I always thought languages that don't specify evaluation order should classify possibly effectful expressions that assume an evaluation order to be errors". Recent work on the C language has provided reasonable formal tools to reason about evaluation order for C, which has very complex evaluation-order rules.

An operational and axiomatic semantics for non-determinism and sequence points in C
Robbert Krebbers
2014

The C11 standard of the C programming language does not specify the execution order of expressions. Besides, to make more effective optimizations possible (e.g. delaying of side-effects and interleav- ing), it gives compilers in certain cases the freedom to use even more behaviors than just those of all execution orders.

Widely used C compilers actually exploit this freedom given by the C standard for optimizations, so it should be taken seriously in formal verification. This paper presents an operational and ax- iomatic semantics (based on separation logic) for non-determinism and sequence points in C. We prove soundness of our axiomatic se- mantics with respect to our operational semantics. This proof has been fully formalized using the Coq proof assistant.

One aspect of this work that I find particularly interesting is that it provides a program (separation) logic: there is a set of inference rules for a judgment of the form \(\Delta; J; R \vdash \{P\} s \{Q\}\), where \(s\) is a C statement and \(P, Q\) are logical pre,post-conditions such that if it holds, then the statement \(s\) has no undefined behavior related to expression evaluation order. This opens the door to practical verification that existing C program are safe in a very strong way (this is all validated in the Coq theorem prover).

Categories: Offsite Discussion

Should OO classes have laws?

Haskell on Reddit - Sun, 09/14/2014 - 1:03am

Please forgive me for being a bit of topic, but I am at this point interested in the oppinions of fellow Haskell programmers about the following.

Many seem to hold the view that type classes should be accompanied by laws (this is my view also). The laws (together with the signatures) are what give the type class its meaning and makes it possible to reason about the code even in the presense of ad hoc overloading.

Do you hold this view about classes in object orientation? (That OO classes should provide laws.) I would like to add that I cannot recall ever to have seen any stated law in OO code.

If you do not think OO classes must have laws, then how should one be able to understand OO code (in the face of inheritance and overloading)? And what then are the classes?

EDIT:

These questions came from a general growing sense I have that object orientation is overused and not really suitable for many of its current applications. (I know others share this.)

I find OO code often complex and difficult to understand and classes almost never accompanied by stated laws.

One problem with OO seem to be that classes are used for (at least) three very different things:

  • To define data structures
  • To encapsulate data with operations
  • To define main control flow

In the first case they serve as a substitute for specialized algebraic datatypes. Take the following java example encoding a type to hold some result of some search computation:

final class Result { final int searchDepth; final int retries; final int visitedNodes; public Result(...) { ... } }

This is a class without laws, because it only serves as a data container. A three-tuple would have been adequate (modulo the nice field names).

In the second case they serve as modules to encapsulate data, for example a map implementation. In this case laws are necessary to understand the class.

In the third case the class is just a container for a set of "toplevel" procedures, like main, to drive the application. Class laws are not really relevant in this case.

submitted by togrof
[link] [15 comments]
Categories: Incoming News