Live data from Hacker News

Mio: A High-Performance Multicore IO Manager for GHC [pdf]

haskell.cs.yale.edu

11–20 of 81 posts

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#11
post #9

Does anyone know why functional programming languages are so much favored by research teams over other types of PL ? Every time i hear someone doing PL research, it's always on some kind of functional programming language such as Haskell or ML.

Enforced purity makes lots of things much easier, STM is a prime example.

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#12
post #9

Does anyone know why functional programming languages are so much favored by research teams over other types of PL ? Every time i hear someone doing PL research, it's always on some kind of functional programming language such as Haskell or ML.

It's not about functional programming languages per se, it's just that a lot of core/academic PL research often focuses much more on concepts than on implementation, and languages with strong type systems (all of which are functional, in part also because OO/subtyping is hard to reason about formally) are ideal for encoding these concepts.

There is, however, a lot of research about implementation going on using other languages as well. Most GC research, for example, is done using JVM and Java programs. For this particular paper, it would be really hard to choose a different platform, though, because GHC is one of the rare industrial runtimes that offer lightweight threads.

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#15
post #9

Does anyone know why functional programming languages are so much favored by research teams over other types of PL ? Every time i hear someone doing PL research, it's always on some kind of functional programming language such as Haskell or ML.

Because (static) FP is built on a sound and rich theory (type theory and lambda calculus) unless other language paradigms (e.g. OO). There are also different approaches, IMHO:

FPL research: Ok, we have this cool way to describe our computation. But how can we efficiently map this to the HW? In essence build a nice language and find an implementation.

Imperative PL research: Ok, we have this HW, how can we build an expressive PL on top of it? In essence build an implementation (the HW) and find a language.

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#16
I've been wondering about garbage collection in pure functional languages lately. It is often said that statically typed pure functional languages allow the compiler to do a lot more correctness checking. Shouldn't the same formal reasoning features also enable much better garbage collection algorithms? Or would that be asking for a solution to the halting problem?

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#17
post #12
post #9

Does anyone know why functional programming languages are so much favored by research teams over other types of PL ? Every time i hear someone doing PL research, it's always on some kind of functional programming language such as Haskell or ML.

It's not about functional programming languages per se, it's just that a lot of core/academic PL research often focuses much more on concepts than on implementation , and languages with strong type systems (all of which are functional, in part also because OO/subtyping is hard to reason about formally) are ideal for encoding these concepts. There is, however, a lot of research about implementation going on using othe…

Exactly. And low-level concurrency research (snapshot algorithms, n-cas) is usually done in C or Java, and so on.

BTW, Java has lightweight threads, too: https://github.com/puniverse/quasar (I'm the main author)

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#18

I've been wondering about garbage collection in pure functional languages lately. It is often said that statically typed pure functional languages allow the compiler to do a lot more correctness checking. Shouldn't the same formal reasoning features also enable much better garbage collection algorithms? Or would that be asking for a solution to the halting problem?

There's lots of interesting optimizations enabled by immutable data. E.g. in generational collectors old data can never point at new data, which can be used to gain additional performance.

see e.g. http://research.microsoft.com/en-us/um/people/simonpj/papers...

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#19
post #12
post #9

Does anyone know why functional programming languages are so much favored by research teams over other types of PL ? Every time i hear someone doing PL research, it's always on some kind of functional programming language such as Haskell or ML.

It's not about functional programming languages per se, it's just that a lot of core/academic PL research often focuses much more on concepts than on implementation , and languages with strong type systems (all of which are functional, in part also because OO/subtyping is hard to reason about formally) are ideal for encoding these concepts. There is, however, a lot of research about implementation going on using othe…

Potentially stupid question: Would they not use Clojure or Scala rather than Java?

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#20
post #9

Does anyone know why functional programming languages are so much favored by research teams over other types of PL ? Every time i hear someone doing PL research, it's always on some kind of functional programming language such as Haskell or ML.

FP is a fertile topic for CS research in part because writing good compilers for FP languages is hard and poses lots of challenging questions for people to try to answer.

Most really low level code generation and parsing research etc. will apply across the board or at least cover a wide range of type of languages (e.g. register allocation, instruction selection).

But consider type theory - a language like Haskell providers a lot wider scope for research in that area than e.g. C. Or garbage collection - admittedly that's more widely applicable, but many FP languages throw an extra factor into the mix with immutable variables. Etc.

But there's certainly other PL research as well. E.g. all the work that's gone into Javascript compilers in the last few years. Trace trees came out of work done on a JVM for example.

Post reply on HN