Re:Functional programming languages should be better at muta...
by zellyn on Tuesday July 30, 2024 @03:46PM
(#41113390)
Came here to say this! Last I heard, the Roc folks were still curious to see whether this bet pays off for most/all codebases.
Re:Functional programming languages should be better at muta...
by sitkack on Tuesday July 30, 2024 @05:04PM
(#41114123)
For those following along https://github.com/roc-lang/roc
https://github.com/multikitty/New-Programming-Languages-Show...
Re:Functional programming languages should be better at muta...
by cryptonector on Tuesday July 30, 2024 @05:17PM
(#41114223)
jq does this. But at the jq language level it looks like mutation creates new values without mutating the old ones.
Re:Functional programming languages should be better at muta...
by rocqua on Tuesday July 30, 2024 @06:03PM
(#41114562)
To what extent is this already being done by other functional blanguages that have CoW mutability?
This seems like a legal compiler optimization to make in most cases no?
Re:Functional programming languages should be better at muta...
by wittystick on Tuesday July 30, 2024 @08:45PM
(#41115523)
Clean has been doing this for nearly as long as people have been using monads, but it never got the attention Haskell did, which I think is quite unfortunate. Rather than implictly keeping track of references, uniqueness types are marked explicitly to inform that their values cannot be aliased. They can also be used with monads to improve ergonomics a bit.
Granule has uniqueness types like Clean built onto a linear type system, which offers some additional advantages.
I think Roc is doing this.