71–80 of 81 posts
Earlier quoted context omitted.
http://en.wikipedia.org/wiki/Pure_function
Pure functions model state nicely. compile :: Source -> Core optimizer :: Core -> Core nativeCode :: Core -> Assembly
Also, how does one encode iterative computation, like a data-flow analysis, in Haskell? And symbol tables? Is it sufficient that the symbol table is encapsulated within compile even if it involves dictionary read/writes? I'm genuinely curious.
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 ex…
Earlier quoted context omitted.
Having state does not mean a function/algorithm is not pure.
http://en.wikipedia.org/wiki/Pure_function
Functional programming languages have mechanisms that make this process pure, simple, and efficient and you get the benefits of never mutating an existing value (which is important when several different functions may hold a reference to it, among other reasons).
See also: The Haskell state monad or lenses. Theses are pure mechanisms that Haskell provides to update state without mutating any data.
Edit: In the event that you do need shared mutable state, the Haskell STM (Shared Transactional Memory) monad is your answer.
It's going to be interesting to revisit techempower's benchmarks when this comes out. http://www.techempower.com/benchmarks/
And high concurrency tends to break MySQL easily. DB is always the bottleneck here, always.
Earlier quoted context omitted.
http://en.wikipedia.org/wiki/Pure_function
Pure functions handle state without any issues (quite elegantly, actually). They simply can't have mutable state that is globally observable. For instance, you could have a struct, and every time you 'mutate' the struct, you actually clone it and simply set the relevant field to the new value when you're instantiating the new struct. Functional programming languages have mechanisms that make this process pure, simple…
I would hope one wouldn't need to resort to STM for a compiler, especially since retry is fairly undefined! Still nothing about iterative computation however, I wonder how the ST monad would deal with a Y combinator?
Earlier quoted context omitted.
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/
But the main problem with subtyping, nominative or structural, is how it messes up Hindley-Damas-Milner style type inference. But that shouldn't be surprising that an FP theory for type inference wouldn't work well for OOP.
It's going to be interesting to revisit techempower's benchmarks when this comes out. http://www.techempower.com/benchmarks/
First of all you have to write a C20M-capable client to replace ab. And high concurrency tends to break MySQL easily. DB is always the bottleneck here, always.
Earlier quoted context omitted.
Pure functions model state nicely. compile :: Source -> Core optimizer :: Core -> Core nativeCode :: Core -> Assembly
Those are just signatures, what is going on inside the boxes? Also, how does one encode iterative computation, like a data-flow analysis, in Haskell? And symbol tables? Is it sufficient that the symbol table is encapsulated within compile even if it involves dictionary read/writes? I'm genuinely curious.
type SymbolTable = Map String Symbol
Here's the iterative code:
https://github.com/Peaker/lamdu/blob/master/Lamdu/Data/Expre...
If you need to internally carry state, you just use a State monad to thread around the state purely.
Earlier quoted context omitted.
> (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…
Not inherently, no, but practically, yes. The type system of, say, Java, isn't even formally sound; overridden functions can be covariant in parameter types, which would not be permissible in a proper subtype-based type system such as OCaml's.