31–40 of 81 posts
Earlier quoted context omitted.
And also there are interesting approaches to "GC optimizations", but so far unported to Haskell: http://www.it.edu/people/mael/mypapers/tldi03.pdf
Thanks, unfortunately I'm getting a 404 Not Found when I click on the link...
Earlier quoted context omitted.
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)
As far as I see you still use the same, standard JVM threads everyone uses, combined with a thread pool.
What am I missing?
Earlier quoted context omitted.
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…
> all of which are functional, in part also because OO/subtyping is hard to reason about formally OO subtyping is hard to reason about formally in formal systems designed for FP...news at 11! I jest. The reason FP does so well academically is that no one knows how to rigorously evaluate something that isn't theoretical (since FP is close to math anyways) or performance-based (most other PL work). The Haskell crowd is…
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.
That's like asking why algebra is preferred among mathematicians over randomly pushing operators and parentheses around hoping that it will work this time.
Earlier quoted context omitted.
Painful to hear about such wonderful developments when you are a Debian Stable user :(
What are the problems of making Haskell from source? (I did it recently, and it takes a long time, and you have to install a bunch of other random things... But at least it works in the end. I guess that sucks for devops?)
From https://plus.google.com/u/0/111990768169655655719/posts/Se5e...
> Cabal is a package manager that by default compiles packages either to a system database (if invoked as root/admin) or a per-user database. Since Haskell code is very often fussy about exact version numbers, and because Cabal offers essentially no way to uninstall packages, this is very painful. Cabal-dev is a front-end to Cabal that gives you per-directory repositories: suddenly conflicts go away, and you can remove packages by deleting the directory's repository and reinstalling everything again. It's a kludge, but it is very helpful.
Cabal-dev: https://github.com/creswick/cabal-dev
---Postscript
Or in stronger terms: http://comments.gmane.org/gmane.comp.lang.haskell.libraries/...
> I would say, "You should never mutate your user or global package database" and recommend using cabal-dev. The way cabal-install does destructive updates is evil. In particular, it likes to mutate your global or user package database. You run the risk of building something and then breaking it later by mutating its dependencies.
Earlier quoted context omitted.
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)
Eh... what exactly is "lightweight" about your threads? As far as I see you still use the same, standard JVM threads everyone uses, combined with a thread pool. What am I missing?
Earlier quoted context omitted.
What are the problems of making Haskell from source? (I did it recently, and it takes a long time, and you have to install a bunch of other random things... But at least it works in the end. I guess that sucks for devops?)
I run into far more version conflicts installing Haskell software through Cabal than any other language environment. Fortunately there is a solution: cabal-dev gives you per-directory package repositories. From https://plus.google.com/u/0/111990768169655655719/posts/Se5e... > Cabal is a package manager that by default compiles packages either to a system database (if invoked as root/admin) or a per-user database. Sin…
Earlier quoted context omitted.
> all of which are functional, in part also because OO/subtyping is hard to reason about formally OO subtyping is hard to reason about formally in formal systems designed for FP...news at 11! I jest. The reason FP does so well academically is that no one knows how to rigorously evaluate something that isn't theoretical (since FP is close to math anyways) or performance-based (most other PL work). The Haskell crowd is…
>> OO subtyping is hard to reason about formally in formal systems designed for FP...news at 11! Well. Even systems like L2 (which are not functional) find subtyping difficult. It becomes difficult in the presence of overloading and overriding.
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?