Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Because I can see it coming: this is a different question than What optimizations can GHC be expected to perform reliably? because I'm not asking for the most reliable optimizations, just the most clever/powerful.
I'm specifically looking for non-intuitive optimizations that GHC makes that can have serious impacts on performance and demonstrate the power of compiler optimizations related to lazy evaluation or purity. And direct explanations about how to get at them.
The best answers will have:
An explanation of the optimization and why it is so clever or powerful
Why the optimization improves performance
How GHC recognizes when it can use this optimization
What the optimization actually transforms the code into
Why this optimization requires lazy evaluation or purity
Stream fusion is probably the biggest one. It turns something like sum . map (+1) . filter (>5), which nominally allocates two new lists, into a simple loop that operates in constant space.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
pure / impure: appears when we talk about the different between Haskell and lisp-family.
safe / unsafe: appears when we name functions like unsafePerformIO, unsafeCoerce.
referential transparency / referential opacity: appears when we emphasize the benefit of purely functional programming.
The difference between these words are very subtle, I find there is some post talking about them individually, but I'm still hoping there is a clear comparison between them, and I can't find such a post here yet.
I've always been fond of Amr Sabry's 1998 paper that explored a similar question with the rigor it deserved: https://www.cs.indiana.edu/~sabry/papers/purelyFunctional.ps
A sample quote:
A language is purely functional if (i) it includes every simply typed
lambda-calculus term, and (ii) its call-by-name, call-by-need, and
call-by-value implementations are equivalent modulo divergence and
errors.
While this question can generate a lot of "opinion" based answers (which I am carefully avoiding!), reading through Amr's paper can put you in the right mindset about how to think about this question; regardless whether you end up agreeing with him or not.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I have some code in Haskell that is using pattern matching. However, I think that I can use folds and filters. For me this would be more readable, but I want to know it there is any advantage in terms of complexity.
The main reason to use higher-order functions instead of pattern matching and manual recursion is that it makes your code more concise and way easier to read.
Once you get the hang of them, you'll find that reading source code suddenly became way easier as those functions are amongst the most popular in all of Haskell.
It's also considered a good practice, and many people appreciate that you abstract your code.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm worried that approach to asynchronous exceptions in GHC might be a net-loss for many applications.
While the paper explains the design to a great detail, it's too complex for average programmers to tell whether this approach provides any benefits at all in their daily work.
Section 2 lists four reasons for current approach (speculative computation, timeouts, user interrupt and resource exhaustion). In my opinion, three are about ability to cancel computations and one is about ability to recover from resource exhaustion which I find questionable (is there any publicly available code that demonstrates this?).
In particular, as mentioned in the paper, Java deprecated Thread.stop() because aborted computation would result in undefined state. Aren't IO actions in GHC subject to the same? Add laziness and the API becomes much more complex in comparison for no clear benefit to most applications.
To summarize, if GHC used the same approach as Java (safe-points, interrupt polling) what would be the consequences to the ecosystem?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
What advantage is using (what I understand as) advanced compiler techniques like special grammar, AST, etc over simple string manipulation for making very small programming languages? I'm interested in compiler design and don't know wether I should learn all of this compiler theory if I'm only going to make small and simple languages. I know that as I start to make bigger languages I will probably have to use parser generators and the like, but until then should I bother?
You should definitely know what an AST is and how to build one. Even if you use parser generators later on. I mean, how can you be interested in compiler design but not in grammar and syntax trees? It always pays off to learn how stuff works under the hood, rather than taking it as magic.
And seriously, parsing anything else than Whitespace or Brainf*ck is awful with string manipulation as soon as it gets more complicated...
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
So, purely functional languages have their own class of potentials due to the clear separation between pure and impure code. I have seen several features that are somewhat simpler to implement in Haskell like Nested Data Parallelism or Stream Fusion.
My question is, what are other improvements/optimizations that are more or less unique to Haskell in terms of feasibility/simplicity but not yet implemented? (I mostly care about GHC, but also love to hear about others)
One optimization I'd love to see in GHC is supercompilation. That seems unlikely in the near-future of GHC, though, because it's whole-program optimization, and GHC is very focused on module-at-a-time compilation.
Basically, supercompilation is executing as much of a program as possible at compile time. It naturally subsumes inlining, deforestation, specialization, and any number of other techniques. Early experimental results have been promising, but it's a very expensive process. It's hard to see it being a practical optimization, but the concept is ridiculously awesome.
Another issue that SPJ states in his paper on modular supercompilation is combining supercompilation with unboxing. Possibilities for unboxing in supercompiled program are significantly reduced. This causes decrease in performance in comparison with unoptimized program passed through GHC strict-analyser/unboxer. See http://research.microsoft.com/en-us/um/people/simonpj/papers/supercompilation/
Another powerful but also "not yet ready for production use" technique is worker-wrapper transformation.