- Haskell-Cafe - Haskell.org

To seq or not to seq, that is the question
by Edward Z. Yang 22 Mar '13

22 Mar '13

Are these equivalent? If not, under what circumstances are they not equivalent? When should you use each? evaluate a >> return b a `seq` return b return (a `seq` b) Furthermore, consider: - Does the answer change when a = b? In such a case, is 'return $! b' permissible? - What about when b = () (e.g. unit)? - What about when 'return b' is some arbitrary monadic value? - Does the underlying monad (e.g. if it is IO) make a difference? - What if you use pseq instead of seq? In http://hackage.haskell.org/trac/ghc/ticket/5129 we a bug in 'evaluate' deriving precisely from this confusion. Unfortunately, the insights from this conversation were never distilled into a widely publicized set of guidelines... largely because we never really figured out was going on! The purpose of this thread is to figure out what is really going on here, and develop a concrete set of guidelines which we can disseminate widely. Here is one strawman answer (which is too complicated to use in practice): - Use 'evaluate' when you mean to say, "Evaluate this thunk to HNF before doing any other IO actions, please." Use it as much as possible in IO. - Use 'return (a `seq` b)' for strictness concerns that have no relation to the monad. It avoids unnecessary strictness when the value ends up never being used and is good hygiene if the space leak only occurs when 'b' is evaluated but not 'a'. - Use 'return $! a' when you mean to say, "Eventually evaluate this thunk to HNF, but if you have other thunks which you need to evaluate to HNF, it's OK to do those first." In particular, (return $! a) >> (return $! b) === a `seq` (return $! b) === a `seq` b `seq` return b === b `seq` a `seq` return b [1] This situation is similar for 'a `seq` return ()' and 'a `seq` m'. Avoid using this form in IO; empirically, you're far more likely to run into stupid interactions with the optimizer, and when later monadic values maybe bottoms, the optimizer will be justified in its choice. Prefer using this form when you don't care about ordering, or if you don't mind thunks not getting evaluated when bottoms show up. For non-IO monads, since everything is imprecise anyway, it doesn't matter. - Use 'pseq' only when 'par' is involved. Edward

3 4

Fwd: A Thought: Backus, FP, and Brute Force Learning
by Eli Frey 22 Mar '13

22 Mar '13

---------- Forwarded message ---------- From: Eli Frey <eli.lee.frey(a)gmail.com> Date: Wed, Mar 20, 2013 at 4:56 PM Subject: Re: [Haskell-cafe] A Thought: Backus, FP, and Brute Force Learning To: OWP <owpmailact(a)gmail.com> I have not read Bacchus' paper, so i might be off the mark here. Functional code is just as simple (if not more so) to puzzle apart and understand as imperative code. You might find that instead of "stepping through the process" of code, you end up "walking the call graph" more often. FPers tend to break their problem into ever smaller parts before re-assembling them back together, often building their own vocabulary as they go. Not to say this is not done in imperative languages, but it is not so heavily encouraged and embraced. One result of this is that you can easily understand a piece of code in isolation, without considering it's place in some "process". It sounds as though you are not yet comfortable with this yet. So yes, you might have to learn more vocabulary to understand a piece of functional code. This is not because the inner workings are obfuscated, but because there are so many more nodes in the call graph that are given names. You can still go and scrutinize each of those new pieces of vocabulary by themselves and understand them without asking for the author to come down from on high with his explanation. Let's take iteration for example. In some imperative languages, people spend an awful lot of time writing iteration in terms of language primitives. You see a for loop. "What is this for loop doing?" you say to yourself. So you step through the loop imagining how it behaves as it goes and you say "Oh, this guy is walking through the array until he finds an element that matches this predicate." In a functional style, you would reuse some iterating function and give it functions to use as it is iterating. The method of iteration is still there, it has just nested into the call graph and if you've never seen that function name before you've got to go look at it. Again I don't mean to suggest that this isn't happening in an imperative language, just not to the same degree. As well there is a bit of a learning curve in seeing what a function "does" when there is no state or "doing" to observe in it. Once you get used to it, I believe you will find it quite nice though. You have probably heard FPers extolling the virtues of "declarative" code. When there is no state or "process" to describe, you end up describing what a thing is. I for one think this greatly increases readability. Good Luck! Eli On Wed, Mar 20, 2013 at 3:59 PM, OWP <owpmailact(a)gmail.com> wrote: > I made an error. I meant FP to stand for Functional Programming, the > concept not the language. > > On Wed, Mar 20, 2013 at 6:54 PM, OWP <owpmailact(a)gmail.com> wrote: > >> This thought isn't really related to Haskell specifically but it's more >> towards FP ideal in general. >> >> I'm new to the FP world and to get me started, I began reading a few >> papers. One paper is by John Backus called "Can Programming Be Liberated >> from the von Neumann Style? A Functional Style and It's Algebra of >> Programs". >> >> While I like the premise which notes the limitation of the von Neumann >> Architecture, his solution to this problem makes me feel queasy when I read >> it. >> >> For me personally, one thing I enjoy about a typical procedural program >> is that it allows me to "Brute Force Learn". This means I stare at a >> particular section of the code for a while until I figure out what it >> does. I may not know the reasoning behind it but I can have a pretty >> decent idea of what it does. If I'm lucky, later on someone may tell me >> "oh, that just did a gradient of such and such matrix". In a way, I feel >> happy I learned something highly complex without knowing I learned >> something highly complex. >> >> Backus seems to throw that out the window. He introduces major new terms >> which require me to break out the math book which then requires me to break >> out a few other books to figure out which bases things using archaic >> symbols which then requires me to break out the pen and paper to mentally >> expand what in the world that does. It makes me feel CISCish except >> without a definition book nearby. It's nice if I already knew what a >> "gradient of such and such matrix" is but what happens if I don't? >> >> For the most part, I like the idea that I have the option of Brute Force >> Learning my way towards something. I also like the declarative aspect of >> languages such as SQL which let's me asks the computer of things once I >> know the meaning of what I'm asking. I like the ability to play and learn >> but I also like the ability to declare this or that once I do learn. From >> Backus paper, if his world comes to a reality, it seems like I should know >> what I'm doing before I even start. The ability to learn while coding >> seems to have disappeared. In a way, if the von Neumann bottleneck wasn't >> there, I'm not sure programming would be as popular as it is today. >> >> Unfortunately, I'm still very new and quite ignorant about Haskell so I >> do not know how much of Backus is incorporated in Haskell but so far, in >> the start of my FP learning adventure, this is how things seem to be seen. >> >> If I may generously ask, where am I wrong and where am I right with this >> thought? >> >> Thank you for any explanation >> >> P.S. If anyone knows of a better place I can ask this question, please >> feel free to show me the way. >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

1 0

Fwd: A Thought: Backus, FP, and Brute Force Learning
by Eli Frey 22 Mar '13

22 Mar '13

I always forget to reply-all :( ---------- Forwarded message ---------- From: Eli Frey <eli.lee.frey(a)gmail.com> Date: Thu, Mar 21, 2013 at 5:04 PM Subject: Re: [Haskell-cafe] A Thought: Backus, FP, and Brute Force Learning To: OWP <owpmailact(a)gmail.com> Ah, ye old "point free programming" [1]. Yes when you first see this stile it's a bit alarming. I think it's valid to say you shouldn't take this too far, but IMHO it is a good thing. If it is any more enlightening, it is good to think of this style like building shell pipelines. Depending on your disposition, that might make you more dismayed though :). Personally I like this style because it allows me to very rapidly prototype my ideas. When I am fleshing some solution out I will write it nearly entirely in this style. As I am throwing code around and refactoring, I will reevaluate things and name my pipes and their inputs and outputs where it makes sense to increase legibility. I am sure that Bacchus is serious about this, but have no fear. Just because you can do this does not mean you have to. You are still free to name your inputs and outputs as much as you please. However, no-one is forcing you to. There is a parallel in languages that have syntactic support for OOP. obj.dothis.dothat.andthis.andthat.andanotherthing There is just as much debate about how far to go with method chaining, and when to name intermediate values. [1] https://en.wikipedia.org/wiki/Tacit_programming On Thu, Mar 21, 2013 at 4:21 PM, OWP <owpmailact(a)gmail.com> wrote: > Thank you for this reply. This thought is more about Backus (he is cited > quite a lot) and how much of his theory made it into Haskell and other > commonly used functional programming. > > In Backhu's paper ( > http://www.thocp.net/biographies/papers/backus_turingaward_lecture.pdf) > is his comparison between FP and Impertive as seen in 5.1 & 5.2 of > "Programs for Inner Product". > > When I start seeing that program described as: > > "Def Innerproduct = (Insert +) o (ApplyToAll x) o Transpose" > > I start getting queasy. When he later describes functional programming > main purpose is to expand on that, I get worried. When he later explains > how I don't need to use variables and just need to use "elementary > substitution rule" for everything, I'm wondering if he's really serious > about this. > > From what you say, it doesn't sound as bad and I hope it isn't as I learn > more. > > Thanks for the reply. > > On Wed, Mar 20, 2013 at 7:56 PM, Eli Frey <eli.lee.frey(a)gmail.com> wrote: > >> I have not read Bacchus' paper, so i might be off the mark here. >> >> Functional code is just as simple (if not more so) to puzzle apart and >> understand as imperative code. You might find that instead of "stepping >> through the process" of code, you end up "walking the call graph" more >> often. FPers tend to break their problem into ever smaller parts before >> re-assembling them back together, often building their own vocabulary as >> they go. Not to say this is not done in imperative languages, but it is >> not so heavily encouraged and embraced. One result of this is that you can >> easily understand a piece of code in isolation, without considering it's >> place in some "process". It sounds as though you are not yet comfortable >> with this yet. >> >> So yes, you might have to learn more vocabulary to understand a piece of >> functional code. This is not because the inner workings are obfuscated, >> but because there are so many more nodes in the call graph that are given >> names. You can still go and scrutinize each of those new pieces of >> vocabulary by themselves and understand them without asking for the author >> to come down from on high with his explanation. >> >> Let's take iteration for example. In some imperative languages, people >> spend an awful lot of time writing iteration in terms of language >> primitives. You see a for loop. "What is this for loop doing?" you say to >> yourself. So you step through the loop imagining how it behaves as it goes >> and you say "Oh, this guy is walking through the array until he finds an >> element that matches this predicate." In a functional style, you would >> reuse some iterating function and give it functions to use as it is >> iterating. The method of iteration is still there, it has just nested into >> the call graph and if you've never seen that function name before you've >> got to go look at it. Again I don't mean to suggest that this isn't >> happening in an imperative language, just not to the same degree. >> >> As well there is a bit of a learning curve in seeing what a function >> "does" when there is no state or "doing" to observe in it. Once you get >> used to it, I believe you will find it quite nice though. You have >> probably heard FPers extolling the virtues of "declarative" code. When >> there is no state or "process" to describe, you end up describing what a >> thing is. I for one think this greatly increases readability. >> >> Good Luck! >> Eli >> >> >> On Wed, Mar 20, 2013 at 3:59 PM, OWP <owpmailact(a)gmail.com> wrote: >> >>> I made an error. I meant FP to stand for Functional Programming, the >>> concept not the language. >>> >>> On Wed, Mar 20, 2013 at 6:54 PM, OWP <owpmailact(a)gmail.com> wrote: >>> >>>> This thought isn't really related to Haskell specifically but it's more >>>> towards FP ideal in general. >>>> >>>> I'm new to the FP world and to get me started, I began reading a few >>>> papers. One paper is by John Backus called "Can Programming Be Liberated >>>> from the von Neumann Style? A Functional Style and It's Algebra of >>>> Programs". >>>> >>>> While I like the premise which notes the limitation of the von Neumann >>>> Architecture, his solution to this problem makes me feel queasy when I read >>>> it. >>>> >>>> For me personally, one thing I enjoy about a typical procedural program >>>> is that it allows me to "Brute Force Learn". This means I stare at a >>>> particular section of the code for a while until I figure out what it >>>> does. I may not know the reasoning behind it but I can have a pretty >>>> decent idea of what it does. If I'm lucky, later on someone may tell me >>>> "oh, that just did a gradient of such and such matrix". In a way, I feel >>>> happy I learned something highly complex without knowing I learned >>>> something highly complex. >>>> >>>> Backus seems to throw that out the window. He introduces major new >>>> terms which require me to break out the math book which then requires me to >>>> break out a few other books to figure out which bases things using archaic >>>> symbols which then requires me to break out the pen and paper to mentally >>>> expand what in the world that does. It makes me feel CISCish except >>>> without a definition book nearby. It's nice if I already knew what a >>>> "gradient of such and such matrix" is but what happens if I don't? >>>> >>>> For the most part, I like the idea that I have the option of Brute >>>> Force Learning my way towards something. I also like the declarative >>>> aspect of languages such as SQL which let's me asks the computer of things >>>> once I know the meaning of what I'm asking. I like the ability to play and >>>> learn but I also like the ability to declare this or that once I do learn. >>>> From Backus paper, if his world comes to a reality, it seems like I should >>>> know what I'm doing before I even start. The ability to learn while coding >>>> seems to have disappeared. In a way, if the von Neumann bottleneck wasn't >>>> there, I'm not sure programming would be as popular as it is today. >>>> >>>> Unfortunately, I'm still very new and quite ignorant about Haskell so I >>>> do not know how much of Backus is incorporated in Haskell but so far, in >>>> the start of my FP learning adventure, this is how things seem to be seen. >>>> >>>> If I may generously ask, where am I wrong and where am I right with >>>> this thought? >>>> >>>> Thank you for any explanation >>>> >>>> P.S. If anyone knows of a better place I can ask this question, please >>>> feel free to show me the way. >>>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> >

1 0

ANN: text-printer - abstract interface for text builders/printers
by Mikhail Vorozhtsov 22 Mar '13

22 Mar '13

Hello, I was writing a library for working with IP addresses when I found myself puzzled with the number of contexts in which the textual representation of an address could be used: plain strings, bytestring builders (ASCII/UTF8), text builders, pretty printers, etc. I could've just written an `addressToString :: Address -> String` function, but that would be suboptimal: (a) namespace pollution (that's a lot of *ToString's if you count IPv4/6, network addresses, socket addresses, etc) and (b) some contexts can take advantage of the fact that textual representations are ASCII (e.g. UTF8 bytestring builder). And so the text-printer[1] was born. It is mainly two type classes. One for injecting text into a monoid, with special methods for ASCII and UTF-8 characters/strings. The other provides the default injection for values of a type (think of the `Pretty` type class in pretty printing libraries), the textual representation is supposed to be simple (single-line). Plus some convenient combinators and number formatters. [1] http://hackage.haskell.org/package/text-printer

1 0

ANN: bytestring-lexing 0.4.3
by wren ng thornton 22 Mar '13

22 Mar '13

-------------------------------------------- -- bytestring-lexing 0.4.3 -------------------------------------------- The bytestring-lexing package offers efficient reading and packing of common types like Double and Integral types. -------------------------------------------- -- Changes (since 0.4.2) -------------------------------------------- * Fixed a segfault bug in packDecimal. Due to the optimizations introduced in 0.4.2, packDecimal could segfault when passed a value larger than (maxBound::Word64). This patch corrects the oversight, and is a recommended upgrade for all users. Unfortunately, the safety test results in a 1.19x slowdown over version 0.4.2; reducing the 1.28x speedup for 0.4.0-->0.4.2 to a mere 1.08x for 0.4.0-->0.4.3. Future versions will probably introduce a type class to remove the safety check for types where it must vacuously succeed. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/bytestring-lexing Darcs: http://community.haskell.org/~wren/bytestring-lexing Haddock (Darcs version): http://community.haskell.org/~wren/bytestring-lexing/dist/doc/html/bytestri… -- Live well, ~wren

1 0

2nd CFP: SBLP 2013 (17th Brazilian Symposium on Programming Languages)
by Andre Rauber Du Bois 21 Mar '13

21 Mar '13

[Apologies if you receive multiple copies of this CFP] ======================================================= 2nd CALL FOR PAPERS 17th BRAZILIAN SYMPOSIUM ON PROGRAMMING LANGUAGES Brasília, Distrito Federal, Brazil September 29th to October 4th, 2013 http://cbsoft2013.cic.unb.br/sblp ======================================================== IMPORTANT DATES Paper abstract submission (15 lines): April 19th Full paper submission: April 26th, 2013 Notification of acceptance: May 31st, 2013 Final papers due: June 28th, 2013 INVITED SPEAKERS * Tim Harris, Oracle Labs * More TBA INTRODUCTION The 17th Brazilian Symposium on Programming Languages, SBLP 2013, will be held in Brasília, Brazil, on September 29th to October 4th, 2013. SBLP provides a venue for researchers and practitioners interested in the fundamental principles and innovations in the design and implementation of programming languages and systems. The symposium will be part of the 4th Brazilian Conference on Software: Theory and Practice, CBSoft 2013, http://cbsoft2013.cic.unb.br/, which will host four traditional, well-established symposia: * XXVII Brazilian Symposium on Software Engineering (SBES) * XVII Brazilian Symposium on Programming Languages (SBLP) * XVI Brazilian Symposium on Formal Methods (SBMF) * VII Brazilian Symposium on Components, Software Architecture and Software Reuse (SBCARS) SBLP 2013 invites authors to contribute with technical papers related (but not limited) to: * Program generation and transformation, including domain-specific languages and model-driven development in the context of programming languages. * Programming paradigms and styles, including functional, object-oriented, aspect-oriented, scripting languages, real-time, service-oriented, multithreaded, parallel, and distributed programming. * Formal semantics and theoretical foundations, including denotational, operational, algebraic and categorical. * Program analysis and verification, including type systems, static analysis and abstract interpretation. * Programming language design and implementation, including new programming models, programming language environments, compilation and interpretation techniques. SUBMISSIONS Contributions should be written in Portuguese or English. We solicit papers that should fall into one of two different categories: full papers, with at most 15 pages, or short papers, with at most 5 pages. Full papers submitted in English will be published in a volume of Lecture Notes in Computer Science (LNCS), by Springer (pending approval). For this reason, all papers must be prepared using the LNCS template, available at http://www.springer.com/computer/lncs?SGWID=0-164-6-793341-0. We encourage the submission of short papers reporting on partial results of on-going master dissertations or doctoral theses. All accepted papers will be published in the conference proceedings distributed in a digital media by the CBSOFT organizers. Submissions should be done using SBLP 2013 installation of the EasyChair conference mangement system at http://www.easychair.org/conferences/?conf=sblp2013. As in previous editions, a journal special issue, with selected papers from accepted contributions, is anticipated. Selected papers from 2003 to 2008 editions of SBLP were published in special issues of the Journal of Universal Computer Science, by Springer. The post-proceedings of SBLP from 2009 to 2012, also with selected papers from the conference proceedings, are being edited as special issues of Science of Computer Programming, published by Elsevier. CBSOFT CHAIRS Genaina Nunes Rodrigues, UnB Rodrigo Bonifácio, UnB Diego Aranha, UnB PROGRAMME CHAIRS André Rauber Du Bois, UFPel Phil Trinder, Glasgow University PROGRAMME COMMITTEE Alberto Pardo, Univ. de La Republica Alex Garcia, IME Alvaro Freitas Moreira, UFRGS André Rauber Du Bois, UFPel (co-chair) Andre Santos, UFPE Carlos Camarao, UFMG Christiano Braga, UFF Edwin Brady, University of St. Andrews Fernando Castor Filho, UFPE Fernando Quintão Pereira, UFMG Francisco Heron de Carvalho Junior, UFC Hans-Wofgang Loidl, Heriot-Watt University Jeremy Singer, Glasgow University Joao Saraiva, Universidade do Minho João F. Ferreira, Teesside University Lucilia Figueiredo, UFOP Luis Soares Barbosa, Univ. do Minho Manuel António Martins, Univ. de Aveiro Marcelo A. Maia, UFU Marcello Bonsangue, Leiden Univ/CWI Marcelo d'Amorim, UFPE Marco Tulio Valente, UFMG Mariza A. S. Bigonha, UFMG Martin A. Musicante, UFRN Noemi Rodriguez, PUC-Rio Peter Mosses, Swansea University Phil Trinder, Glasgow University (co-chair) Qiu Zongyang, Beijing University Rafael Dueire Lins, UFPE Renato Cerqueira, PUC-Rio Ricardo Massa, UFPE Roberto S. Bigonha, UFMG Roberto Ierusalimschy, PUC-Rio Sandro Rigo, UNICAMP Sergio Soares, UFPE Simon Thompson, Univ. of Kent Varmo Vene, Univ. de Tartu

1 0

Excercise on tagless final interpreters
by matteo vezzola 21 Mar '13

21 Mar '13

I'm playing with tagless final interpreters reading [1], using a very simple language: >>> class Ints repr where >>> int :: Integer -> repr Integer >>> (.+.) :: repr Integer -> repr Integer -> repr Integer >>> (.*.) :: repr Integer -> repr Integer -> repr Integer >>> (.-.) :: repr Integer -> repr Integer >>> (.<=.) :: repr Integer -> repr Integer -> repr Bool >>> newtype P repr t = P { unP :: Bool -> repr t } >>> instance Ints repr => Ints (P repr) where >>> int n = P $ \ s -> if s then int n else (.-.) (int n) >>> (.-.) n = P $ unP n . not >>> n .+. m = P $ \ s -> unP n s .+. unP m s >>> n .*. m = P $ \ s -> unP n s .*. unP m s >>> n .<=. m = P $ \ s -> unP n s .<=. unP m s After pushing down negations I'd like to distribute (.*.) over (.+.). [1] leaves it as an exercise, so it can't be that hard, but I don't get it... Anyone knows how I could do it? [1]: <http://okmij.org/ftp/tagless-final/course/lecture.pdf> thanks, -- matteo

3 2

Extracting exposed modules from an installed library
by Corentin Dupont 21 Mar '13

21 Mar '13

Hi Cafe! I'm looking for how to extract the exposed modules (as a list of strings) from an installed library, giving the library name. I can see some structures in Cabal (InstalledPackageInfo) and some functions in ghc-pkg.hs in GHC, but nothing readily useable... Thanks, Corenti

3 3

ANN: bytestring-lexing 0.4.2
by wren ng thornton 21 Mar '13

21 Mar '13

-------------------------------------------- -- bytestring-lexing 0.4.2 -------------------------------------------- The bytestring-lexing package offers efficient reading and packing of common types like Double and Integral types. -------------------------------------------- -- Changes (since 0.4.0) -------------------------------------------- * Faster implementation of packDecimal. Inspired by [1] I applied the same optimizations to the ByteString implementation of packDecimal. According to the benchmarks I have on hand the new version is about 1.3x faster than the old version. So the difference isn't nearly as impressive; but it's not trivial either. * Added buffer overflow check for asHexadecimal. This only matters if you try converting a ByteString longer than (maxBound `quot` 2 ::Int). I forget if the old version segfaulted or what; but now you get an error message about trying to allocate a buffer that's too large. [1] <http://www.serpentine.com/blog/2013/03/20/whats-good-for-c-is-good-for-hask…> -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/bytestring-lexing Darcs: http://community.haskell.org/~wren/bytestring-lexing Haddock (Darcs version): http://community.haskell.org/~wren/bytestring-lexing/dist/doc/html/bytestri… -- Live well, ~wren

1 0

Haskell Weekly News: Issue 263
by Daniel Santa Cruz 21 Mar '13

21 Mar '13

Welcome to issue 263 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers the week of March 10 to 16, 2013. Quotes of the Week * shachaf: Did someone give edwardk a committee bit? Top Reddit Stories * Restored: the Haskell mailing list archives: 1990-2000. The lost books of Haskell Domain: code.haskell.org, Score: 71, Comments: 9 On Reddit: [1] http://goo.gl/wYs4E Original: [2] http://goo.gl/1Hw4G * Dependently Typed Functional Programming with Idris [video] Domain: vimeo.com, Score: 49, Comments: 20 On Reddit: [3] http://goo.gl/RDII5 Original: [4] http://goo.gl/AmmPJ * Snake game in Haskell Domain: self.haskell, Score: 48, Comments: 19 On Reddit: [5] http://goo.gl/HssiG Original: [6] http://goo.gl/HssiG * A simple graphical notation for lambda calculus Domain: binarylambda.blogspot.com, Score: 46, Comments: 35 On Reddit: [7] http://goo.gl/I3xqp Original: [8] http://goo.gl/sY6gl * Simon Peyton Jones on Adventures with types (Functional Programming eXchange 2013) Domain: skillsmatter.com, Score: 46, Comments: 27 On Reddit: [9] http://goo.gl/wUvon Original: [10] http://goo.gl/XCWsE * Guide to GHC Extensions (just some simple ones for now, will expand over time) - School of Haskell Domain: fpcomplete.com, Score: 42, Comments: 25 On Reddit: [11] http://goo.gl/XhFK5 Original: [12] http://goo.gl/Wa0K3 * layers-0.1: Modular type class machinery for monad transformer stacks. Domain: hackage.haskell.org, Score: 37, Comments: 30 On Reddit: [13] http://goo.gl/nkimL Original: [14] http://goo.gl/HFBxI * Type Families and Pokemon: School of Haskell Pick of the Week Domain: fpcomplete.com, Score: 35, Comments: 3 On Reddit: [15] http://goo.gl/mITH3 Original: [16] http://goo.gl/oymkn * Gale: an IDE for creating games in Haskell Domain: youtube.com, Score: 31, Comments: 4 On Reddit: [17] http://goo.gl/2k28x Original: [18] http://goo.gl/9SxFS * What is the best way to make a simple web service in Haskell? Domain: self.haskell, Score: 31, Comments: 34 On Reddit: [19] http://goo.gl/sVAe7 Original: [20] http://goo.gl/sVAe7 * Wadler's Blog: Informatics 1: Functional Programming Domain: wadler.blogspot.ro, Score: 25, Comments: 3 On Reddit: [21] http://goo.gl/70Ocg Original: [22] http://goo.gl/z4b38 * Constructions on Typeclasses, Part 1: F-Algebras Domain: lukepalmer.wordpress.com, Score: 24, Comments: 0 On Reddit: [23] http://goo.gl/qGsVj Original: [24] http://goo.gl/s947R * cabal-dev updated on hackage Domain: haskell.org, Score: 24, Comments: 37 On Reddit: [25] http://goo.gl/LUOQZ Original: [26] http://goo.gl/nMut4 * monoid-subclasses: ListLike-like, only built on sound theoretical foundations Domain: hackage.haskell.org, Score: 22, Comments: 24 On Reddit: [27] http://goo.gl/gA46h Original: [28] http://goo.gl/4QOKw * Introduction to Concurrent Haskell - Simon Marlow [FP Days Cambridge 2012] Domain: infoq.com, Score: 22, Comments: 1 On Reddit: [29] http://goo.gl/CS0xV Original: [30] http://goo.gl/TrVo9 Top StackOverflow Questions * Proposal for local data declarations / instances votes: 15, answers: 1 Read on SO: [31] http://goo.gl/VCd4K * What is the equivalent Haskell type for C99 bool when using FFI? votes: 14, answers: 2 Read on SO: [32] http://goo.gl/mm3hC * Disadvantages of using INLINABLE pragma votes: 13, answers: 1 Read on SO: [33] http://goo.gl/zxnBu * How to compare two lists in Haskell? votes: 11, answers: 4 Read on SO: [34] http://goo.gl/kTXqL * Haskell space usage compile time restrictions votes: 11, answers: 2 Read on SO: [35] http://goo.gl/vy7wO * haskell - Average floating point error using QuickCheck votes: 10, answers: 1 Read on SO: [36] http://goo.gl/MNsnL * Trying to understand function application operator in Haskell votes: 9, answers: 1 Read on SO: [37] http://goo.gl/ymFv4 * Haskell equivalent to Scala's groupBy votes: 9, answers: 4 Read on SO: [38] http://goo.gl/0uceW * (Num a) vs Integer type inference votes: 9, answers: 3 Read on SO: [39] http://goo.gl/N3CWn Until next time, +Daniel Santa Cruz References 1. http://code.haskell.org/~dons/haskell-1990-2000/ 2. http://www.reddit.com/r/haskell/comments/1aescj/restored_the_haskell_mailin… 3. http://vimeo.com/61576198 4. http://www.reddit.com/r/haskell/comments/1a7rbk/dependently_typed_functiona… 5. http://www.reddit.com/r/haskell/comments/1a12vg/snake_game_in_haskell/ 6. http://www.reddit.com/r/haskell/comments/1a12vg/snake_game_in_haskell/ 7. http://binarylambda.blogspot.com/2013/03/lambda-diagrams-lambda-diagrams-fe… 8. http://www.reddit.com/r/haskell/comments/1a47ox/a_simple_graphical_notation… 9. http://skillsmatter.com/podcast/java-jee/keynote-3842 10. http://www.reddit.com/r/haskell/comments/1aedqt/simon_peyton_jones_on_adven… 11. https://www.fpcomplete.com/user/PthariensFlame/guide-to-ghc-extensions ? 12. http://www.reddit.com/r/haskell/comments/1a3ye8/guide_to_ghc_extensions_jus… 13. http://hackage.haskell.org/package/layers 14. http://www.reddit.com/r/haskell/comments/1aazok/layers01_modular_type_class… 15. https://www.fpcomplete.com/user/nubis/type-families-and-pokemon 16. http://www.reddit.com/r/haskell/comments/1adukd/type_families_and_pokemon_s… 17. http://www.youtube.com/watch?v=dKBFJa9N3zY 18. http://www.reddit.com/r/haskell/comments/1a3k64/gale_an_ide_for_creating_ga… 19. http://www.reddit.com/r/haskell/comments/1acfbx/what_is_the_best_way_to_mak… 20. http://www.reddit.com/r/haskell/comments/1acfbx/what_is_the_best_way_to_mak… 21. http://wadler.blogspot.ro/2013/03/informatics-1-functional-programming.html 22. http://www.reddit.com/r/haskell/comments/1a5uio/wadlers_blog_informatics_1_… 23. http://lukepalmer.wordpress.com/2013/03/12/constructions-on-typeclasses-par… 24. http://www.reddit.com/r/haskell/comments/1a5dtt/constructions_on_typeclasse… 25. http://www.haskell.org/pipermail/haskell-cafe/2013-February/106719.html 26. http://www.reddit.com/r/haskell/comments/1a6t0j/cabaldev_updated_on_hackage/ 27. http://hackage.haskell.org/package/monoid-subclasses 28. http://www.reddit.com/r/haskell/comments/1a33sb/monoidsubclasses_listlikeli… 29. http://www.infoq.com/presentations/Concurrent-Haskell 30. http://www.reddit.com/r/haskell/comments/1a4pvi/introduction_to_concurrent_… 31. http://stackoverflow.com/questions/15320391/proposal-for-local-data-declara… 32. http://stackoverflow.com/questions/15368658/what-is-the-equivalent-haskell-… 33. http://stackoverflow.com/questions/15440804/disadvantages-of-using-inlinabl… 34. http://stackoverflow.com/questions/15319136/how-to-compare-two-lists-in-has… 35. http://stackoverflow.com/questions/15374829/haskell-space-usage-compile-tim… 36. http://stackoverflow.com/questions/15364518/haskell-average-floating-point-… 37. http://stackoverflow.com/questions/15362990/trying-to-understand-function-a… 38. http://stackoverflow.com/questions/15412027/haskell-equivalent-to-scalas-gr… 39. http://stackoverflow.com/questions/15448351/num-a-vs-integer-type-inference 40. https://plus.google.com/105107667630152149014/about

1 0