3 ms·
It's not possible to do always but it feels like it should be possible in special cases. If you can prove that a value V2 is ultimately derived from a modificat
by philipkglass 4y ago
It's not possible to do always but it feels like it should be possible in special cases. If you can prove that a value V2 is ultimately derived from a modification of V1, and V1 is never referenced after creating V2, then it should be possible to invisibly convert this to an in-place mutation [1]. In the case of applying a bunch of text normalization rules to a string, for example, I care about the final string but not the intermediate states. It could be mutation underneath and I'd be none the wiser, except that the runtime performance would be better.
In Scala you can add a "@tailrec" annotation to recursive functions. The annotation means that the function is guaranteed to recurse efficiently (without growing the stack) OR that the compiler will give an error telling you why it can't be guaranteed. I could imagine a similar annotation like "@withmutation" for functions where you want to guarantee efficient in-place mutation at runtime. As it is, when I run into performance pain points in Scala I redo the critical bits with (manually written) while-loops and imperative mutation.
[1] Unless you later attach a debugger and expect to be able to observe V1 and V2 simultaneously. But I presume this sort of issue already comes up and is somehow dealt with regarding other compiler optimizations.
- cassepipe 4y agoI think this is the idea behind Richard Feldman's Roc programming language https://www.roc-lang.org/ https://www.roc-lang.org/
- riwsky 4y agoAnd just like that, you’ve invented Rust!
- frostwarrior 4y agoAFAIK this is the idea behind ImmutableJS: https://immutable-js.com/ https://immutable-js.com/
- lyxsus 4y agoIsn’t it similar to linear types in haskell?
- eru 4y agoThat's basically exactly the same idea, yes. Haskell didn't invent linear types. Eg Clean had them for ages to do IO. (They didn't use Monads in Clean.)