Defunctionalization: Everybody does it, nobody talks about it (2019)
1–10 of 28 posts
Re: Defunctionalization: Everybody does it, nobody talks about it (2019)
#2So... specialization? It's a very common thing when talking about generics in programming languages, anyway.
Re: Defunctionalization: Everybody does it, nobody talks about it (2019)
#3Put like this defunctionalisation is just eval for a domain-specific-language that you hope doesn't do the things you don't want it to.
Re: Defunctionalization: Everybody does it, nobody talks about it (2019)
#4On continuations:
"This suggests that language-level support for defunctionalization could be used to keep the beauty of explicit continuations while gaining the scalability of multiple machines.
A few systems, such as the MFlow and jmacro-rpc frameworks, have tried to circumvent this problem by sending continuations over the wire in a different way: by sending over information about the execution’s past, so that the other machine may replay a function call in order to get to where the first machine left off. This can be seen as an application of my ICFP 2018 paper on thermometer continuations."
Re: Defunctionalization: Everybody does it, nobody talks about it (2019)
#5The thing is, and the article correctly mentions it, that defunctionalization sacrifices composability. This is not just a technical matter, mind you. If you design your distributed system around defunctionalized higher-order functions, you have to ensure that client and server have the same understanding of valid parameters. That's a non-trivial problem.
So while this might be a cool technique for whole-program compilers, I think it doesn't really fit into anything that has an API boundary.
Re: Defunctionalization: Everybody does it, nobody talks about it (2019)
#6The article in video form:
Re: Defunctionalization: Everybody does it, nobody talks about it (2019)
#7i,m too dumb for this ideza
Re: Defunctionalization: Everybody does it, nobody talks about it (2019)
#8His discussion of how refactorings can be described as mechanical transformations is worth reading for itself. In fact, the logical, mechanical nature of refactorings is why there are tools that can do them automatically, at least in languages where the code can be statically analyzed for them.
Re: Defunctionalization: Everybody does it, nobody talks about it (2019)
#9Interesting article, to me it just appears to be deciding how much you know at compile time vs runtime. (Runtime expressibility vs compile-time proofs) If you make your code a DSL you’re implicitly limiting your code to the semantics of your DSL, (you know at compile time that your code will do some finite set of things) while if you enable arbitrary code to be passed as higher order functions you lose this compile time knowledge. In the distributed systems case this is a positive because you want to limit the behavior of programs sent over the wire for security reasons.
Re: Defunctionalization: Everybody does it, nobody talks about it (2019)
#10Discussed at the time:
Defunctionalization: Everybody Does It, Nobody Talks About It - https://news.ycombinator.com/item?id=21916774 - Dec 2019 (20 comments)