[HN Gopher] Mazeppa: A modern supercompiler for call-by-value fu...
___________________________________________________________________
Mazeppa: A modern supercompiler for call-by-value functional
languages
Author : Jhsto
Score : 138 points
Date : 2024-07-12 09:04 UTC (2 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| 082349872349872 wrote:
| Is the manual annotation is because deciding whether or not a
| graph will blow up upon supercompilation by trying, but checking
| for blowup during the process, doesn't work?
|
| > _In Mazeppa, we have call-by-value functions and call-by-name
| (call-by-need) constructors, which 1) makes deforestation
| possible and 2) preserves the original semantics of code._
|
| Are there any other notable differences between this approach and
| call-by-value constructors? (I guess one might have to carry
| around the original context in closures for a little while, but
| presumably even that disappears in residual programs?)
|
| [Stepan Razin lost his black hat during his ride, but the
| supercompiler has already removed Ivan Mazepa's?]
| Hirrolot wrote:
| Checking for blowup sort of works; for example, this paper [1]
| suggests exactly this approach. However, I'm not leaning to it
| due to the following reasons:
|
| 1. The approach involves magic numbers to implement heuristics.
| They worked for the samples provided by the authors, but will
| they work for large programs?
|
| 2. I think that there's a smarter approach to detect blowups.
| Specifically, there can be "good" and "bad" interactions in the
| form `f(g(...), ...)`, where `f` and `g` are functions; an
| interaction is good if `g` produces information that is known
| at compile-time (to be subsequently deconstructed by `f`), and
| bad if it doesn't. If the interaction is bad, `f` and `g`
| should be transformed separately.
|
| In general, I see manual annotations as a low-level mechanism
| that can be used for predictable supercompilation. We haven't
| yet implemented heuristics that would guarantee predictability,
| but this is on our priority list.
|
| > Are there any other notable differences between this approach
| and call-by-value constructors?
|
| Yes, lazy constructors must be implemented differently than
| eager ones. The standard approach is to enclose constructor
| arguments under an environment of values, just as we implement
| closure functions. I don't think that supercompilation can
| remove all laziness from the constructors.
|
| [1] Jonsson, Peter & Nordlander, Johan. (2011). Taming code
| explosion in supercompilation. PERM'11 - Proceedings of the
| 20th ACM SIGPLAN Workshop on Partial Evaluation and Program
| Manipulation. 33-42. 10.1145/1929501.1929507.
| keiferski wrote:
| The likely origin of the name, if you're curious:
|
| https://en.wikipedia.org/wiki/Mazeppa_(poem)
| rottc0dd wrote:
| Oh! I thought it was this:
|
| https://youtu.be/CXGeOHdiHrE
|
| TIL
| Hirrolot wrote:
| The name was inspired by Transcendental Etude No. 4 [1], as
| correctly suggested by the other comment.
|
| [1] https://www.youtube.com/watch?v=MYSFTtYc4P4
| keiferski wrote:
| It looks like those compositions were ultimately inspired by
| the poem. So we're both right ;)
|
| https://en.wikipedia.org/wiki/Cultural_legacy_of_Mazeppa
| parhamn wrote:
| That was such a good Readme. Wonderful explanations for those
| unfamiliar with the space, full examples, a bit of
| history/context. Thanks!
| Hirrolot wrote:
| Thanks, I'm glad the explanations were helpful.
___________________________________________________________________
(page generated 2024-07-14 23:01 UTC)