News aggregator

submitted by dstcruz
[link] [comment]

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.

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]

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)

submitted by sideEffffECt
[link] [comment]

(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

submitted by 5outh
[link] [20 comments]

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.

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.

submitted by geezusfreeek
[link] [1 comment]

submitted by felipelessa
[link] [27 comments]

submitted by lsmag
[link] [19 comments]

Dear Haskell Hackers, I have started an advice page for people that plan to submit experience reports to the upcoming Haskell Symposium, based on my experience as a PC member last year: http://www.haskell.org/haskellwiki/HaskellSymposium/ExperienceReports Haskell Symposium experience report acceptance rates are typically lower than for full papers, and it would be good to improve this. Please add any comments, links or insights you may have to the above page. If you are planning to submit an experience report... then also read the page! :-) Ben. _______________________________________________ Haskell mailing list Haskell< at >haskell.org http://www.haskell.org/mailman/listinfo/haskell

Hello there, could somebody please shed some light on the following line that appeared in my ~/.cabal/config? remote-build-reporting: anonymous The option doesn't seem to be documented anywhere, and I'm very nervous about undocumented "remote reporting" features. I expect cabal-install to communicate only to fetch the latest package index and to upload and download packages, the former only when i actually use the "upload" command. If it performs any other communication, please tell me how to disable it. In that case I'd also be interested in an explanation for why this was enabled in the first place. I certainly didn't enable it myself, because it would be a serious security breach in my case. Thank you. Greets, Ertugrul

hi all it seems i have met some bug on a MAC 32bit GHC version 7.4.2 to make long stroy short, my code is about parse a json file using aeson here is my code http://pastebin.com/0VcVhdvX and here is test data http://pastebin.com/PvtSvst5 and test steps save the code , and name it a.hs (or what you want) save the test data ,name it a.json (do not change its name) $ ghc a.hs -o a $ ./a what i get from the output is "fail" and when i run the command below for a few times $ runghc a.hs i even got some ok and some fail mixed together but i copy the code and compile it on my linux, everything goes fine, the output is "OK" i have run "uninstall-hs" and install a 64bit ghc, also goes fine i delete one line randomly chosen from my test data , got an ok roll back ,delete another line, also an ok... I just want to make sure is this my bug or a bug of ghc p.s. the reason using 32bit ghc is yesod, which has met another bug on 64bit mac ghc :( thanks sray

Link to the PhD student positions:

http://www.gu.se/english/about_the_university/announcements-in-the-job-application-portal/?languageId=100001&contentId=-1&disableRedirect=true&returnUrl=http%3A%2F%2Fwww.gu.se%2Fomuniversitetet%2Faktuellt%2Fledigaanstallningar%2F%3Fid%3D19144%26Dnr%3D537224%26Type%3DS&id=19144&Dnr=537224&Type=S

Link to the post-doc positions:

http://www.gu.se/english/about_the_university/announcements-in-the-job-application-portal/?languageId=100001&contentId=-1&disableRedirect=true&returnUrl=http%3A%2F%2Fwww.gu.se%2Fomuniversitetet%2Faktuellt%2Fledigaanstallningar%2F%3Fid%3D19144%26Dnr%3D537259%26Type%3DS&id=19144&Dnr=537259&Type=S

submitted by koenclaessen
[link] [2 comments]

L.S., Apologies for multiple copies, please forward to whomever you deem appropriate. Please find enclosed the Call for Participation for the Second International Workshop on Trends in Functional Programming In Education (TFPIE). Since the closing of submissions, we have come up with a tentative program for the workshop. Some details, including the title and abstract for the invited talk are to follow. Keep an eye on the website [1]. The program is as follows: 09:00-09:30 From Principles to Practice with Class in the First Year, Sam Tobin-Hochstadt and David Van Horn 09:30-10:00 Structural Induction Principles for Functional Programmers, James Caldwell 10:00-10:30 Hardware design in education using CλaSH, Rinse Wester, Jan Kuper and Christiaan Baaij 10:30-10:45 Break 10:45-12:15 Invited talk: Matthew Flatt 12:15-13:45 Lunch 13:45-14:15 Racket Fun-ctional Programming to Elementary Mathematic Teachers, Dalit Levy 14:15-14:45 Functional Reactive Programming in K12 Education, John Peterson an

Quoth Wikipedia:

Big data[1][2] is a collection of data sets so large and complex that it becomes difficult to process using on-hand database management tools or traditional data processing applications. The challenges include capture, curation, storage,[3] search, sharing, transfer, analysis,[4] and visualization. The trend to larger data sets is due to the additional information derivable from analysis of a single large set of related data, as compared to separate smaller sets with the same total amount of data, allowing correlations to be found to “spot business trends, determine quality of research, prevent diseases, link legal citations, combat crime, and determine real-time roadway traffic conditions.”

Now what if we get tired of the current hype cycle?

Big fucking deal[1][2] is a collection of deals so fucking large and complex that it becomes difficult to process using on-hand fuck giving tools or traditional shit giving techniques. The challenges include capture, curation, storage,[3] search, sharing, transfer, analysis,[4] and all kinds of who the fuck knows what else. The trend to larger fucking deals is due to the additional shit derivable from giving a fuck about a single large fucking pile of related shit, as compared to separate smaller piles with the same total amount of bullshit, allowing correlations to be found to “spot business shit, determine quality of whatever, prevent some nasty shit, link legal shit right the fuck together, combat fucking crime no I am not making this up it’s like fucking Batman, and determine real-time traffic shittiness.”