News aggregator


Haskell on Reddit - Fri, 07/18/2014 - 3:25am
Categories: Incoming News

Extensible Effects & Multiple Operations

haskell-cafe - Thu, 07/17/2014 - 9:43pm
I am playing around with the extensible-effects framework and cannot figure out how to solve this problem. I am trying to define a set of operations that only work after a file has been opened. For example, reading a character from a file or detecting EOF. My problem is I cannot figure out how to define one "runner" for my Effect that can deal with operations with different result types. For example, I would like my `readFrom` and `atEOF` operations to have the following types: data OpenFile r v = ... -- my "OpenFile" effect -- read a character from the file readFrom :: Eff r Char -- detect EOF atEOF :: Eff r Bool And I would like to use this operations as follows (where I read a byte from the file, check EOF, and return the concatenation of the two values): main = do c <- runOpenFile "Setup.hs" (do a <- readFrom -- `a` has `Char` type eof <- atEOF -- `eof` has `Bool` type return $ [a] ++ show eof) putStrLn c However, I cannot define a `runOpenFile` that
Categories: Offsite Discussion

Workshop on Evaluation and Usability of Programming Languages and Tools (PLATEAU)

Lambda the Ultimate - Thu, 07/17/2014 - 4:19pm

We are having another PLATEAU workshop at SPLASH 2014. We have a new category for "Hypotheses Papers" and thought this would be particularly appealing to the LTU community.

Programming languages exist to enable programmers to develop software effectively. But how efficiently programmers can write software depends on the usability of the languages and tools that they develop with. The aim of this workshop is to discuss methods, metrics and techniques for evaluating the usability of languages and language tools. The supposed benefits of such languages and tools cover a large space, including making programs easier to read, write, and maintain; allowing programmers to write more flexible and powerful programs; and restricting programs to make them more safe and secure.

PLATEAU gathers the intersection of researchers in the programming language, programming tool, and human-computer interaction communities to share their research and discuss the future of evaluation and usability of programming languages and tools.

Some particular areas of interest are:
- empirical studies of programming languages
- methodologies and philosophies behind language and tool evaluation
- software design metrics and their relations to the underlying language
- user studies of language features and software engineering tools
- visual techniques for understanding programming languages
- critical comparisons of programming paradigms
- tools to support evaluating programming languages
- psychology of programming

Submission Details

PLATEAU encourages submissions of three types of papers:

Research and position papers: We encourage papers that describe work-in-progress or recently completed work based on the themes and goals of the workshop or related topics, report on experiences gained, question accepted wisdom, raise challenging open problems, or propose speculative new approaches. We will accept two types of papers: research papers up to 8 pages in length; and position papers up to 2 pages in length.

Hypotheses papers: Hypotheses papers explicitly identify beliefs of the research community or software industry about how a programming language, programming language feature, or programming language tool affects programming practice. Hypotheses can be collected from mailing lists, blog posts, paper introductions, developer forums, or interviews. Papers should clearly document the source(s) of each hypothesis and discuss the importance, use, and relevance of the hypotheses on research or practice. Papers may also, but are not required to, review evidence for or against the hypotheses identified. Hypotheses papers can be up to 4 pages in length.

Papers will be published in the ACM Digital Library at the authors’ discretion.

Important Dates

Workshop paper submission due - 1 August, 2014
Notification to authors - 22 August, 2014
Early registration deadline - 19 September, 2014


Josh Bloch, former Chief Java Architect at Google and Distinguished Engineer at Sun Microsystems.

Categories: Offsite Discussion

[Fixed] cc1.exe extraction error on install of Haskell Platform

Haskell on Reddit - Thu, 07/17/2014 - 12:07pm

I want to archive this solution if anyone else hits this issue.

On x64 Windows installing 2013.2.0.0

Close all running programs, for me this included but was not limited to eclipse, skype and firefox. I'm not sure which was the offender. Now re-run the installer and you should be good.

This post doesn't need upvotes but i want to store this solution for if someone searches for it.

submitted by IndexPlusPlus
[link] [1 comment]
Categories: Incoming News

[noob question] Monadic equivalent to <*

Haskell on Reddit - Thu, 07/17/2014 - 11:57am

Sorry for the newbie question, but Google wasn't too helpful (googlebot doesn't parse punctuation).

Is there a Monadic equivalent to <* that I've overlooked? Something like << ? I find myself doing things like:

mobitFoo >>= (\x -> bar >> return x)


do x <- mobitFoo bar return x

Also, I've only been Haskelling for a little while, and I'm pretty sure this is reason #97 I've found why Applicative should be a superclass of Monad.

submitted by Considered_Harmful
[link] [17 comments]
Categories: Incoming News

Q about last&init

haskell-cafe - Thu, 07/17/2014 - 10:35am
I am teaching myself haskell. The first impression is very good. But phrase "haskell is polynomially reducible" is making me sad :(. Anyway I am trying to backport my algorithm written in C. The key to performance is to have ability to remove element from the end of a list in O(1). But the original haskell functions last and init are O(n). My questions are: 1) Is last function is something like "black box" written in C++ which perform O(1)? So I shouldn't even try to imagine some haskell O(1) equivalent. 2) Or will optimizer (llvm?) reduce init&last complexity to 1? 3) Some people suggest to use sequences package, but still how do they implement O(1) init&last sequences equivalent in haskell?
Categories: Offsite Discussion

Num in value constructor

Haskell on Reddit - Thu, 07/17/2014 - 9:16am

Hi! I've started reading Learn you a haskell for great good! as I suppose most of you guys have read. I'm at the data type section where the author is making a 3D vector type. He goes on saying

Let’s implement a 3D vector type and add some operations for it. We’ll make it a parameterized type, because even though it will usually contain numeric types, it will still support several of them, like Int, Integer, and Double, to name a few.

data Vector a = Vector a a a

But what I truly want is "data Vector = Vector Num Num Num" right? Why is this not possible (or if it is, how to do it?). Num takes a parameter so I tried something like "data Vector a = Vector (Num a) (Num a) (Num a)" but this did not work. So what's the deal?

Thanks for the help!

submitted by frerom
[link] [36 comments]
Categories: Incoming News

Adding to list, GHCI compiling error

Haskell on Reddit - Thu, 07/17/2014 - 8:57am

-- Sample test data

type Sales = (String, String, Int)

-- First String is title of track, Second String is artist name, Int is number of tracks sold

testData :: [Sales]

testData :: [("Me and My Broken Heart","Rixton",5),("It’s My Birthday","",4),("Problem","Ariana Grande",3)]

-- record a sale of a track

sellTrack :: String String Int -> [Sales]

sellTrack :: trackName artistName numberSold = [Sales] ++ [(trackName, artistName, numberSold)]

I get the error "illegal literal in type : "Me and My Broken Heart"

Thanks in advance.

submitted by Rifaz1
[link] [comment]
Categories: Incoming News

Ketil Malde: Information content and allele frequency difference

Planet Haskell - Thu, 07/17/2014 - 6:00am
ESI scores and allele frequency difference

Just a quick note on the relationship between ESI scores and allele frequencies. Allele frequency differences is of course related to – perhaps even the definition of – diversification, but the information we gain from observing an allele also depends on the specific allele frequencies involved. The graph below shows how this is related.

Each line represents a fixed allele difference, from 0.05 at the bottom, to 0.95 at the top, and the x-axis is the average allele frequency between populations. We see that for small differences, the actual frequencies matter little, but for moderate to large allele differences, allele frequencies near the extremes have a large effect.

Note that this is information per allele, and thus not ESI (which is the expected information from observing the site, in other words a weighted average over all alleles).

Categories: Offsite Blogs

Opening .hs files on GHCi

Haskell on Reddit - Thu, 07/17/2014 - 5:57am

Hi everyone, new to haskell and trying to open my .hs file.

I've tried ":cd" and ":L" both the haskell platform and my .hs file is on my desktop.

Any help would be appreciated, Thanks all.

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

Haskell Weekly News: Issue 299

haskell-cafe - Thu, 07/17/2014 - 4:30am
Welcome to issue 299 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers from June 29 to July 12, 2014 Quotes of the Week * donri: maybe good thing Applicative isn't called StrongLaxSemimonoidalEndofunctor * ninja_code: haskell is used to debug thinking * johnw: the first rule of category theory club is to state your identity Top Reddit Stories * The new design Domain:, Score: 130, Comments: 95 Original: [1] On Reddit: [2] * GHC-7.8.3 is out! Domain:, Score: 115, Comments: 40 Original: [3] On Reddit: [4] * Announcing rest - A Haskell REST framework Domain:, Score: 97, Comments: 41 Original: [5] On Reddit: [6] * GHC plans for 7.10.1 Domain:, Score:
Categories: Offsite Discussion

Problems with type family in a class

haskell-cafe - Thu, 07/17/2014 - 3:32am
Hi, Consider the following type classes: class (Signal sx) => Complexable sx where type ComplexSignalType .... class (Complexable sx) => FourierTransformable sx where fft :: (cx ~ ComplexSignalType sx) => cx -> cx .... and an instance: instance (RealFloat e) => Complexable [e] where type ComplexSignalType = [Complex e] instance (RealFloat e) => FourierTransformable [e] where fft = ... Why this example will give errors: *DSP.Signals.Core Prelude Data.Complex> :t ax ax :: [Complex Double] *DSP.Signals.Core Prelude Data.Complex> fft ax <interactive>:90:1: No instance for (FourierTransformable s0 [Complex Double]) arising from a use of ‘fft’ The type variable ‘s0’ is ambiguous Note: there is a potential instance available: instance [overlap ok] (RealFloat e, Math.FFT.Base.FFTWReal e) => FourierTransformable [e] [Complex e]
Categories: Offsite Discussion

help with multiparam type class

haskell-cafe - Thu, 07/17/2014 - 2:40am
Hi, Given any Event constructor, the 'conv' method passes in the field name to 'val' for each field. There is a Z instance for each Event arity. The call "conv E1::E1" works but requires that I explicitly specify the type. Is there any way to avoid that having to do that? For some reason 'conv' does not have enough information to know the type. Is there a way to do this with functional dependencies or type classes or something else? Here is the paste and here is the error: *Main> conv E1 <interactive>:3:1: No instance for (Z e0 (String -> E1)) arising from a use of `conv' The type variable `e0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there are several potential instances: instance (Event e, Field a) => Z e (a -> e) -- Defined at testfamily.hs:28:10 instance Event e => Z e e -- Defined at testfamily.hs:20:10 Possible fix: add an instance declaration for (Z e0 (String -> E1)) In the express
Categories: Offsite Discussion

extra "ambiguous type variable" errors after a "couldn't match" error?

glasgow-user - Thu, 07/17/2014 - 2:32am
7.8.3 has a new behaviour where a "plain" type error will cause "ambiguous type variable" errors, e.g.: module M where broken :: [Int] broken = () ambiguous :: a -> [String] ambiguous _ = map show [1..] When imported in ghci, I get: M.hs:4:10: Couldn't match expected type ‘[Int]’ with actual type ‘()’ In the expression: () In an equation for ‘broken’: broken = () M.hs:7:19: No instance for (Show a0) arising from a use of ‘show’ The type variable ‘a0’ is ambiguous [ ... and then more for Enum and Num ] It seems like the 'a' type variable causes this to happen. But I don't see why a type error in another place should cause 'ambiguous' to become ambiguous. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >
Categories: Offsite Discussion

add IsList instance to Data.Sequence

libraries list - Wed, 07/16/2014 - 9:36pm
seems like an oversight in ghc 7.8 release of containers, but worth adding! I'm willing to write the patch etc if everyone ok's this discussion period: 2 weeks _______________________________________________ Libraries mailing list Libraries< at >
Categories: Offsite Discussion

Mark Jason Dominus: Guess what this does (solution)

Planet Haskell - Wed, 07/16/2014 - 6:00pm

A few weeks ago I asked people to predict, without trying it first, what this would print:

perl -le 'print(two + two == five ? "true" : "false")'

(If you haven't seen this yet, I recommend that you guess, and then test your guess, before reading the rest of this article.)

People familiar with Perl guess that it will print true; that is what I guessed. The reasoning is as follows: Perl is willing to treat the unquoted strings two and five as strings, as if they had been quoted, and is also happy to use the + and == operators on them, converting the strings to numbers in its usual way. If the strings had looked like "2" and "5" Perl would have treated them as 2 and 5, but as they don't look like decimal numerals, Perl interprets them as zeroes. (Perl wants to issue a warning about this, but the warning is not enabled by default. Since the two and five are treated as zeroes, the result of the == comparison are true, and the string "true" should be selected and printed.

So far this is a little bit odd, but not excessively odd; it's the sort of thing you expect from programming languages, all of which more or less suck. For example, Python's behavior, although different, is about equally peculiar. Although Python does require that the strings two and five be quoted, it is happy to do its own peculiar thing with "two" + "two" == "five", which happens to be false: in Python the + operator is overloaded and has completely different behaviors on strings and numbers, so that while in Perl "2" + "2" is the number 4, in Python is it is the string 22, and "two" + "two" yields the string "twotwo". Had the program above actually printed true, as I expected it would, or even false, I would not have found it remarkable.

However, this is not what the program does do. The explanation of two paragraphs earlier is totally wrong. Instead, the program prints nothing, and the reason is incredibly convoluted and bizarre.

First, you must know that print has an optional first argument. (I have plans for an article about how optional first argmuents are almost always a bad move, but contrary to my usual practice I will not insert it here.) In Perl, the print function can be invoked in two ways:

print HANDLE $a, $b, $c, …; print $a, $b, $c, …;

The former prints out the list $a, $b, $c, … to the filehandle HANDLE; the latter uses the default handle, which typically points at the terminal. How does Perl decide which of these forms is being used? Specifically, in the second form, how does it know that $a is one of the items to be printed, rather than a variable containing the filehandle to print to?

The answer to this question is further complicated by the fact that the HANDLE in the first form could be either an unquoted string, which is the name of the handle to print to, or it could be a variable containing a filehandle value. Both of these prints should do the same thing:

my $handle = \*STDERR; print STDERR $a, $b, $c; print $handle $a, $b, $c;

Perl's method to decide whether a particular print uses an explicit or the default handle is a somewhat complicated heuristic. The basic rule is that the filehandle, if present, can be distinguished because its trailing comma is omitted. But if the filehandle were allowed to be the result of an arbitrary expression, it might be difficult for the parser to decide where there was a a comma; consider the hypothetical expression:

print $a += EXPRESSION, $b $c, $d, $e;

Here the intention is that the $a += EXPRESSION, $b expression calculates the filehandle value (which is actually retrieved from $b, the $a += … part being executed only for its side effect) and the remaining $c, $d, $e are the values to be printed. To allow this sort of thing would be way too confusing to both Perl and to the programmer. So there is the further rule that the filehandle expression, if present, must be short, either a simple scalar variable such as $fh, or a bare unqoted string that is in the right format for a filehandle name, such as `HANDLE``. Then the parser need only peek ahead a token or two to see if there is an upcoming comma.

So for example, in

print STDERR $a, $b, $c;

the print is immediately followed by STDERR, which could be a filehandle name, and STDERR is not followed by a comma, so STDERR is taken to be the name of the output handle. And in

print $x, $a, $b, $c;

the print is immediately followed by the simple scalar value $x, but this $x is followed by a comma, so is considered one of the things to be printed, and the target of the print is the default output handle.


print STDERR, $a, $b, $c;

Perl has a puzzle: STDERR looks like a filehandle, but it is followed by a comma. This is a compile-time error; Perl complains “No comma allowed after filehandle” and aborts. If you want to print the literal string STDERR, you must quote it, and if you want to print A, B, and C to the standard error handle, you must omit the first comma.

Now we return the the original example.

perl -le 'print(two + two == five ? "true" : "false")'

Here Perl sees the unquoted string two which could be a filehandle name, and which is not followed by a comma. So it takes the first two to be the output handle name. Then it evaluates the expression

+ two == five ? "true" : "false"

and obtains the value true. (The leading + is a unary plus operator, which is a no-op. The bare two and five are taken to be string constants, which, compared with the numeric == operator, are considered to be numerically zero, eliciting the same warning that I mentioned earlier that I had not enabled. Thus the comparison Perl actually does is is 0 == 0, which is true, and the resulting string is true.)

This value, the string true, is then printed to the filehandle named two. Had we previously opened such a filehandle, say with

open two, ">", "output-file";

then the output would have been sent to the filehandle as usual. Printing to a non-open filehandle elicits an optional warning from Perl, but as I mentioned, I have not enabled warnings, so the print silently fails, yielding a false value.

Had I enabled those optional warnings, we would have seen a plethora of them:

Unquoted string "two" may clash with future reserved word at -e line 1. Unquoted string "two" may clash with future reserved word at -e line 1. Unquoted string "five" may clash with future reserved word at -e line 1. Name "main::two" used only once: possible typo at -e line 1. Argument "five" isn't numeric in numeric eq (==) at -e line 1. Argument "two" isn't numeric in numeric eq (==) at -e line 1. print() on unopened filehandle two at -e line 1.

(The first four are compile-time warnings; the last three are issued at execution time.) The crucial warning is the one at the end, advising us that the output of print was directed to the filehandle two which was never opened for output.

[ Addendum 20140718: I keep thinking of the following remark of Edsger W. Dijkstra:

[This phenomenon] takes one of two different forms: one programmer places a one-line program on the desk of another and … says, "Guess what it does!" From this observation we must conclude that this language as a tool is an open invitation for clever tricks; and while exactly this may be the explanation for some of its appeal, viz., to those who like to show how clever they are, I am sorry, but I must regard this as one of the most damning things that can be said about a programming language.

But my intent is different than what Dijkstra describes. His programmer is proud, but I am discgusted. Incidentally, I believe that Dijkstra was discussing APL here. ]

Categories: Offsite Blogs