Painful to hear about such wonderful developments when you are a Debian Stable user :(
Installing GHC manually is not hard, the website even provides pre-compiled binaries. I started doing it for different reasons, but was surprised how painless the process was. After doing it multiple times, I wrote together a file that guides me through the process, which you can find here: https://github.com/quchen/articles/blob/master/install_haske...
Thanks for that nice guide! I was actually expecting to install GHC by hand eventually (for now, 7.4 is sufficient).
I know that part of the reason I like FP is that a compiler is usually a pretty perfect pure function - source code -> machine code. So those people researching languages will often find that FP is the best tool for their job and will be most familiar with it. Then when they come to research something new they do it in the context they're most familiar with.
Symbol table, multiple passes, iterative processing.... The state is not event-based in nature but does exist.
Having state does not mean a function/algorithm is not pure.
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?
The fact that it's not using standard JVM threads? His blog post describes how everything works: http://blog.paralleluniverse.co/post/49445260575/quasar-puls...
This blog post is extremely vague and handwavy.
Looking into the actual source code didn't reveal anything “special” either, so I'll just call bullshit on these claims.
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?
It should, yes. AIUI the state of the art in the JVM is that we can do all the marking and sweeping in parallel, it's just heap compaction that requires a "stop the world" pause. If the VM had visibility over which objects were referentially transparent, it should be possible to compact those easily.
(Sadly even that doesn't mean a truly pauseless garbage collector - the "heap of non-referentially transparent objects" will still eventually fragment to the point of filling up)
The fact that it's not using standard JVM threads? His blog post describes how everything works: http://blog.paralleluniverse.co/post/49445260575/quasar-puls...
This blog post is extremely vague and handwavy. Looking into the actual source code didn't reveal anything “special” either, so I'll just call bullshit on these claims. Feel free to prove me wrong.
I don't know what you mean by "special" (nor do I understand which "claims" you have issue with), but these are true lightweight threads. We use runtime bytecode transformation to create continuation, so that we can suspend and later resume a call-stack. These continuations are then scheduled on a thread-pool. It works exactly like it does in any other lightweight thread implementation AFAIK, except that in languages such as Erlang or Haskell, these continuations are created by the compiler or by the runtime, while in Quasar they're created with bytecode transformation. The JVM doesn't support continuations out of the box, but its instrumentation mechanism allows you to implement them in a library. It isn't any more, or less, special than lightweight threads in Erlang or Haskell.
OO subtyping is hard to reason about formally in formal systems _in general_.
And yet, is-a and has-a relationships predominate natural language. Well, it makes sense: natural language is hard to reason about formally also.
The problem isn't that `is-a` is hard, it's the divergence of `is-subtype-of` and `is-subclass-of`. Take a look here, I think it explains it rather well.
http://okmij.org/ftp/Computation/Subtyping/
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.
The HN community is particularly receptive to functional programing. HN itself is written in Arc which is a language implemented in Racket. There's still active research in Fortran i.e. for super computers etc., check out the SIGPLAN Fortran Forum [1]. OOPSLA/SPLASH has lots of non-functional language research [2]. Also check out PLDI, arguably one of the most prestigious PL conferences. Scala, Dart, and LLVM feature…
HN also sits inside a center tag using a table with width="85%", as I recently found out while trying to override its CSS rules. It's bizarre that an organization so forward looking uses deprecated html tags.
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?
With a purely linear type system, memory management could be handled statically, negating the need for traditional GC. The underlying behavior would be closer to C-style just-in-time {de-}allocation, or C++ RAII. LinearML is an attempt at this: https://github.com/pikatchu/LinearML
Regarding Linear Type Systems and friends I recommend reading parts of Jesse Tov's PhD thesis [1], "Practical Programming with Substructural Types". I found parts of it pretty accessible as an undergraduate. In particular he uses substructural types to put types on the network protocol of a server and client. Neat stuff.
There's also the wikipedia page on Substructural Types [2].
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?
With a purely linear type system, memory management could be handled statically, negating the need for traditional GC. The underlying behavior would be closer to C-style just-in-time {de-}allocation, or C++ RAII. LinearML is an attempt at this: https://github.com/pikatchu/LinearML
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 NOT orthogonal to functional, nor is it inherently at odds with formal reasoning. OCaml has both imperative and functional objects; Haskell, Mercury, and Coq (a formal logic language) all support typeclasses, which subsume most of OO and provide subtyping. Additionally, strong typing has little to do wi…
hence if you are trying to prove anything about code in, say, C, you need to augment the code with explicit state and remove all non-local effects. (See: the Why language, which attempts to bridge this gap.)
Actually, you just need to augment your model with notions of state, which is standard in operational semantics. It can just be harder to prove things in a complex model, so theorists prefer simplification when possible.