News aggregator

steve-yegge.blogspot.fr

del.icio.us/haskell - Thu, 05/02/2013 - 2:32am
Categories: Offsite Blogs

lpuppet.banquise.net

del.icio.us/haskell - Thu, 05/02/2013 - 2:32am
Categories: Offsite Blogs

lpuppet.banquise.net

del.icio.us/haskell - Thu, 05/02/2013 - 2:32am
Categories: Offsite Blogs

lpuppet.banquise.net

del.icio.us/haskell - Thu, 05/02/2013 - 2:32am
Categories: Offsite Blogs

lpuppet.banquise.net

del.icio.us/haskell - Thu, 05/02/2013 - 2:32am
Categories: Offsite Blogs

lpuppet.banquise.net

del.icio.us/haskell - Thu, 05/02/2013 - 2:32am
Categories: Offsite Blogs

lpuppet.banquise.net

del.icio.us/haskell - Thu, 05/02/2013 - 2:32am
Categories: Offsite Blogs

lpuppet.banquise.net

del.icio.us/haskell - Thu, 05/02/2013 - 2:32am
Categories: Offsite Blogs

lpuppet.banquise.net

del.icio.us/haskell - Thu, 05/02/2013 - 2:32am
Categories: Offsite Blogs

Simplifying Core pretty-printing via GHC API?

glasgow-user - Wed, 05/01/2013 - 10:13pm
I'm using the GHC API to compile Haskell source code to Core. I'd like to pretty-print the result with the sort of simplifications I get with -dsuppress-type-applications, -dsuppress-uniques, etc (used in combination with -ddump-simpl on ghc's command line). How can I set these options via the GHC API? Has the answer changed since 7.4.1 (which I'm currently using)? Thanks. - Conal _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Categories: Offsite Discussion

Haskell Weekly News: Issue 266

Haskell on Reddit - Wed, 05/01/2013 - 10:06pm
Categories: Incoming News

Manuel M T Chakravarty: Seminar by Dave Thomas on "VMs Demystified – A Tour of the Engine Room"

Planet Haskell - Wed, 05/01/2013 - 8:43pm

Dave Thomas, who is widely known for his work on virtual machines and the YOW! Australia conference series, will be in Sydney this month. He kindly agreed to talk about VMs at CSE. Anybody with an interest in VM engineering and programming language implementations should mark the date in their calendar!

Time: 29 May 2013 (Wed), 11AM

Location: CSE Seminar room (K17_113), Level 1, CSE Building (K17)

Title: VMs Demystified – A Tour of the Engine Room

Speaker: David Thomas (Bedarra Research Labs and YOW! Developer Conference)

Also showing at: The talk is also presented at ScalaSyd the previous evening, 28 May, 18:30 — details here

Abstract

Language virtual machines are an essential part of current and next generation platforms.  Yet many developers have no real idea of what is actually happening when their program is run on a VM or the hardware.  This leads to many false assumptions about speed and space performance.  In this talk you will see under the hood of language virtual machines and gain an understanding of what makes VMs tick as well as differences between the languages they support.

First we explain the essence VM engineering including object representations, stack versus register VMs, RISC versus CISC byte codes; static dispatch to polymorphic inline cache; context management; interpretation versus dynamic translation/tracing versus compilation; garbage collection; and native types and code interfaces. We discuss benchmark speed and space performance versus real application performance.

Armed with the above knowledge we then engage in some of the entertaining educational VM debates. How can a JVM or PHP VM faster than C++? When is the JVM or CLR better? How does the language, or the language library impact the VM? Are strongly typed languages always faster than dynamic languages? How does hosting with CRuby, compare to JRuby or Java? Let’s put the VM in hardware? How do functional language VMs differ from object VMs? How can thousands of processes in Erlang be efficient compared to using native OS threads?

Bio

Dave Thomas is an expert in dynamic languages and has decades of experience building and deploying language VMs for mobile, instrumentation, embedded command and control, and business application on platforms from mainframes to micro devices. He is widely known and respected in the programming language community and this year will be presenting the keynote at the Commercial Users of Functional Programming (CUFP) conference. While CEO of OTI, now IBM OTI Labs, he over saw IBM’s Smalltalk and J9 family of Java enterprise and embedded JVMs, OSGi as well as the initial releases of Eclipse. He lead an IBM OTI research effort into universal virtual machines. After leaving IBM he worked on JVM support for dynamic languages and the use of V8 for embedded applications. For the past 6 years Dave has been working with high performance vector functional virtual machines, DSLs and most recently exploring special purpose HW VMs.

Categories: Offsite Blogs

Question about Haskell's Laziness

Haskell on Reddit - Wed, 05/01/2013 - 7:13pm

TL;DR Is Haskell independently lazy about the values of a tuple? For a tuple (a,b), if a is always used but b is sometimes used can Haskell be lazy about b?

I am currently completeing an assignment where we are writing an interpreter for another programming language. One of the challenges is to add a debug option from the command line and have our program print debug output for the execution of the program. My implentation of this involves starting with an empty string which is passed through to every function to either add something to the debug string, pass it onto any called function to add something to it and then return whatever is passed back or the same debug string. At the end of the evaluation i have a tuple:

(result, debugString)

and if the debug flag was set then I putStrLn the debugString and otherwise I just putStrLn $ show results. I know this may be difficult to understand but my question is: If the debug flag is not set and I never call putStrLn debugString, will Haskell still evaluate the debug string (essentially a heap of string concatenations) or will it's laziness mean it never bothers. My uncertainty relates to the fact that it is a tuple and can Haskell be independently lazy about elements of a tuple?

Happy to clairfy if you leave questions in the comments.

submitted by someGuyOnAComputer
[link] [31 comments]
Categories: Incoming News

Haskell 2014

General haskell list - Wed, 05/01/2013 - 2:39pm
Dear Haskellers, We are pleased to announce that the Haskell 2014 committee has now formed, and we would be delighted to receive your proposals for changes to the language. Please see http://hackage.haskell.org/trac/haskell-prime/wiki/Process for details on the proposal process. The committee will meet 4 times a year, to consider proposals completed before: * 1st August * 1st November * 1st February * 1st May so if you have been meaning to put the finishing touches to a proposal, then we would encourage you to do so by the end of July! The source for the Haskell report will be updated as proposals are accepted, but new versions of the standard will only be released once a year, during January. The Haskell 2014 committee is comprised of: * Carlos Camarão * Iavor Diatchki * Ian Lynagh (chair) * John Meacham * Neil Mitchell * Ganesh Sittampalam * David Terei * Bas van Dijk * Henk-Jan van Tuyl Thanks Ian (Haskell 2014 committee chair)
Categories: Incoming News

2 PhD student and 2 Post-doc positions at Gothenburg University, in Language Technology / Formal Methods

General haskell list - Wed, 05/01/2013 - 11:03am
(Please spread this to interested candidates, application deadline is May 13th.) We warmly welcome applicants with a strong background in functional programming! ---- The Department of Computer Science and Engineering (CSE) at the University of Gothenburg and Chalmers University of Technology announces 2 PhD positions and 2 post-doc positions within the research project "Reliable Multilingual Digital Communication: Methods and Applications (REMU)" funded by the Swedish Research Council (Vetenskapsrådet). The CSE Department provides a strong, international, and dynamic research environment with about 70 faculty and 70 PhD students from about 30 countries. The PhD positions are located jointly in two research groups: Language Technology and Formal Methods. The PhD supervisors will be professors from these groups: Aarne Ranta (REMU principal scientist), Koen Claessen, and Gerardo Schneider. ---- Link to the PhD student positions: http://www.gu.se/english/about_the_university/announcements-in-the-job
Categories: Incoming News

Symbolic Calculus in Haskell

Haskell on Reddit - Wed, 05/01/2013 - 10:27am
Categories: Incoming News

What is the process for GSOC?

haskell-cafe - Wed, 05/01/2013 - 9:34am
How is it decided which Haskell projects get chosen? Do we discuss them here and take a collective view? Thanks, Dominic. PS I should point out I have an interest in the proposal to port charts to use diagrams (http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/jbracker/1) i.e. I'd really like this as a user.
Categories: Offsite Discussion

Disciple/DDC: Array fusion using the lowering transform

Planet Haskell - Wed, 05/01/2013 - 8:38am
I'm getting back into blogging. This is current work in progress.
Repa 4 will include a GHC plugin that performs array fusion using a version of Richard Waters's series expressions system, extended to support the segmented operators we need for Data Parallel Haskell.
The plugin converts GHC core code to Disciple Core, performs the fusion transform, and then converts back to GHC core. We're using Disciple Core for the main transform because it has a simple (and working) external core format, and the core language AST along with most of the core-to-core transforms are parametric in the type used for names. This second feature is important because we use a version of Disciple Core where the main array combinators (map, fold, filter etc) are primitive operators rather than regular function bindings.
The fusion transform is almost (almost) working for some simple examples. Here is the compilation sequence:

Haskell Source

process :: Stream k Int -> Intprocess s = fold (+) 0 s + fold (*) 1 s
In this example we're performing two separate reductions over the same stream. None of the existing short-cut fusion approaches can handle this properly. Stream fusion in Data.Vector, Repa-style delayed array fusion, and build/foldr fusion will all read the stream elements from memory twice (if they are already manifest) or compute them twice (if they are delayed). We want to compute both reductions in a single pass.

Raw GHC core converted to DDC core

repa_process_r2 : [k_aq0 : Data].Stream_r0 k_aq0 Int_3J -> Int_3J  = \(k_c : *_34d).\(s_aqe : Stream_r0 k_c Int_3J).    $fNumInt_$c+_rjF       (fold_r34 [k_c] [Int_3J] [Int_3J] $fNumInt_$c+_rjF                  (I#_6d 0i#) s_aqe)       (fold_r34 [k_c] [Int_3J] [Int_3J] $fNumInt_$c*_rjE                  (I#_6d 1i#) s_aqe)

Detect array combinators from GHC core, and convert to DDC primops
repa_process_r2 : [k_aq0 : Rate].Stream# k_aq0 Int# -> Int# = /\(k_c : Rate).    \(s_aqe : Stream# k_c Int#).   add# [Int#]        (fold# [k_c] [Int#] [Int#] (add# [Int#]) 0i# s_aqe)        (fold# [k_c] [Int#] [Int#] (mul# [Int#]) 1i# s_aqe)

Normalize and shift array combinators to top-levelAll array combinators are used in their own binding.
repa_process_r2 : [k_aq0 : Rate].Stream# k_aq0 Int# -> Int# = /\(k_c : Rate).    \(s_aqe : Stream# k_c Int#).   let x0 = add# [Int#] in   let x1 = fold# [k_c] [Int#] [Int#] x0 0i# s_aqe in   let x2 = mul# [Int#] in   let x3 = fold# [k_c] [Int#] [Int#] x2 1i# s_aqe in   add# [Int#] x1 x3

Inline and eta-expand worker functionsThis puts the program in the correct form for the next phase.
repa_process_r2 : [k_aq0 : Rate].Stream# k_aq0 Int# -> Int# = /\(k_c : Rate).    \(s_aqe : Stream# k_c Int#).   let x1        = fold# [k_c] [Int#] [Int#]                (\(x0 x1 : Int#). add# [Int#] x0 x1) 0i# s_aqe in   let x3        = fold# [k_c] [Int#] [Int#]                (\(x2 x3 : Int#). mul# [Int#] x2 x3) 1i# s_aqe in    add# [Int#] x1 x3

Do the lowering transformThis is the main pass that performs array fusion. Note that we've introduced a single loop# that computes both of the fold# results.
repa_process_r2 : [k_c : Rate].Stream# k_c Int# -> Int# = /\(k_c : Rate).    \(s_aqe : Stream# k_c Int#).   let x1_acc : Ref# Int# = new# [Int#] 0i# in   let x3_acc : Ref# Int# = new# [Int#] 1i# in   let _ : Unit        = loop# (lengthOfRate# [k_c])                (\(x0 : Nat#).                let x1 : Int# = next# [Int#] [k_c] s_aqe x0 in                let x0 : Int# = read# [Int#] x1_acc in                let _  : Void#                       = write# [Int#] x1_acc (add# [Int#] x0 x1) in                let x2 : Int# = read# [Int#] x3_acc in                let _  : Void#                       = write# [Int#] x3_acc (mul# [Int#] x2 x1) in                   ()) in   let x1 : Int# = read# [Int#] x1_acc in   let x3 : Int# = read# [Int#] x3_acc in   add# [Int#] x1 x3

Assign imperative variable storage to arraysWe need to convert the code back to GHC core, but we don't want to use IORefs because they can't hold unboxed values (of types like Int#). Instead, we use some new arrays to hold these values instead.
repa_process_r2 : [k_c : Rate].Stream# k_c Int# -> Int# = /\(k_c : Rate).    \(s_aqe : Stream# k_c Int#).   let x1_acc : Array# Int# = newArray# [Int#] 8# in   let _      : Void#       = writeArray# [Int#] x1_acc 0# 0i# in   let x3_acc : Array# Int# = newArray# [Int#] 8# in   let _      : Void#       = writeArray# [Int#] x3_acc 0# 1i# in   let _ : Unit         = loop# (lengthOfRate# [k_c])                 (\(x0 : Nat#).                  let x1 : Int# = next# [Int#] [k_c] s_aqe x0 in                  let x0 : Int# = readArray# [Int#] x1_acc 0# in                  let _ : Void#                        = writeArray# [Int#] x1_acc 0#                               (add# [Int#] x0 x1) in                  let x2 : Int# = readArray# [Int#] x3_acc 0# in                  let _ : Void#                         = writeArray# [Int#] x3_acc 0#                                (mul# [Int#] x2 x1) in                   ()) in      let x1 : Int# = readArray# [Int#] x1_acc 0# in      let x3 : Int# = readArray# [Int#] x3_acc 0# in      add# [Int#] x1 x3

Thread state token through effectful primopsThe lowered code is naturally imperative, and GHC uses state threading to represent this. 
repa_process_r2 : [k_c : Rate].Stream# k_c Int# -> World# -> Tuple2# World# Int#    = /\(k_c : Rate).       \(s_aqe : Stream# k_c Int#).\(x0 : World#).      caselet T2# (x1 : World#) (x1_acc : Array# Int#)         = newArray# [Int#] 8# x0 in      caselet T2# (x2 : World#) (_ : Void#)         = writeArray# [Int#] x1_acc 0# 0i# x1 in      caselet T2# (x3 : World#) (x3_acc : Array# Int#)         = newArray# [Int#] 8# x2 in      caselet T2# (x4 : World#) (_ : Void#)         = writeArray# [Int#] x3_acc 0# 1i# x3 in      caselet T2# (x11 : World#) (_ : Unit)         = loop# (lengthOfRate# [k_c])              (\(x0 : Nat#).\(x5 : World#).               caselet T2# (x6 : World#) (x1 : Int#)                  = next# [Int#] [k_c] s_aqe x0 x5 in               caselet T2# (x7 : World#) (x0 : Int#)                  = readArray# [Int#] x1_acc 0# x6 in               caselet T2# (x8 : World#) (_ : Void#)                  = writeArray# [Int#] x1_acc 0# (add# [Int#] x0 x1) x7 in               caselet T2# (x9 : World#) (x2 : Int#)                  = readArray# [Int#] x3_acc 0# x8 in               caselet T2# (x10 : World#) (_ : Void#)                  = writeArray# [Int#] x3_acc 0# (mul# [Int#] x2 x1) x9 in               T2# x10 ()) x4 in      caselet T2# (x12 : World#) (x1 : Int#)         = readArray# [Int#] x1_acc 0# x11 in      caselet T2# (x13 : World#) (x3 : Int#)         = readArray# [Int#] x3_acc 0# x12 in      T2# x13 (add# [Int#] x1 x3)
Here, "caselet" is just sugar for a case expression with a single alternative.

Covert back to GHC core
repa_process_sTX  :: forall k_c.     Data.Array.Repa.Series.Stream k_c GHC.Types.Int     -> GHC.Prim.State# GHC.Prim.RealWorld     -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Prim.Int# #)[LclId]lowered_sTX =  \ (@ k_c)    (rate_sTY :: GHC.Prim.Int#)    (x_sTZ :: Data.Array.Repa.Series.Stream k_c GHC.Types.Int)    (x_sU0 :: GHC.Prim.State# GHC.Prim.RealWorld) ->    let { (# x_sU1, x_sU2 #) ~ scrut_sUv    <- newByteArray#_sU3 @ GHC.Prim.RealWorld 8 x_sU0    } in    let { __DEFAULT ~ x_sU8    <- writeIntArray#_sU4 @ GHC.Prim.RealWorld x_sU2 0 0 x_sU1    } in    let { (# x_sU5, x_sU6 #) ~ scrut_sUw    <- newByteArray#_sU7 @ GHC.Prim.RealWorld 8 x_sU8    } in    let { __DEFAULT ~ x_sUp    <- writeIntArray#_sU9 @ GHC.Prim.RealWorld x_sU6 0 1 x_sU5    } in    let { (# x_sUa, x_sUb #) ~ x_sUa    <- Main.primLoop         (Main.primLengthOfRate rate_sTY)         (\ (x_sUc :: GHC.Prim.Int#)            (x_sUd :: GHC.Prim.State# GHC.Prim.RealWorld) ->            let { (# x_sUe, x_sU1 #) ~ x_sUe            <- Main.primNext_Int @ k_c x_sTZ x_sUc x_sUd            } in            let { (# x_sUf, x_sUc #) ~ x_sUf            <- readIntArray#_sUg x_sU2 0 x_sUe            } in            let { __DEFAULT ~ x_sUl            <- writeIntArray#_sUh                 @ GHC.Prim.RealWorld x_sU2 0 (+#_sUi x_sUc x_sU1) x_sUf            } in            let { (# x_sUj, x_sU8 #) ~ x_sUj            <- readIntArray#_sUk x_sU6 0 x_sUl            } in            let { __DEFAULT ~ x_sUo            <- writeIntArray#_sUm                 @ GHC.Prim.RealWorld x_sU6 0 (*#_sUn x_sU8 x_sU1) x_sUj            } in            (# x_sUo, GHC.Tuple.() #))         x_sUp    } in    let { (# x_sUq, x_sU1 #) ~ x_sUq    <- readIntArray#_sUr x_sU2 0 x_sUa    } in    let { (# x_sUs, x_sU5 #) ~ x_sUs    <- readIntArray#_sUt x_sU6 0 x_sUq    } in    (# x_sUs, +#_sUu x_sU1 x_sU5 #)

This doesn't work yet because I've forgotten to pass the type arguments to the unboxed tuple constructor (#,#), and maybe other problems as well. I'll post again when I have an actual program running.

Categories: Offsite Blogs