Capture Checking in Scala
nrinaudo.github.io
Capture Checking in Scala
1–10 of 19 posts
Re: Capture Checking in Scala
#2Nice article. It reminds me of another post a little while ago about OCaml. Like OCaml, Scala is getting more systems programming capabilities. Capture checking can, for example, be used to implement safe memory arenas (aka slab allocation or memory pools.) If you can prove that no code has captured anything from the arena, you can prove it is safe to deallocate the arena. This is less fine-grained than Rust's approach, but I think it is much more usable. I think of it as similiar to Zig's approach but with safety guarantees.
The other part, doing away with monads, is also exciting for FP nerds like me, but probably less generally exciting as it doesn't add new capabilities to the language so much as make existing capabilities easier to use (puns intended, of course!)
Re: Capture Checking in Scala
#3Nice article. It reminds me of another post a little while ago about OCaml. Like OCaml, Scala is getting more systems programming capabilities. Capture checking can, for example, be used to implement safe memory arenas (aka slab allocation or memory pools.) If you can prove that no code has captured anything from the arena, you can prove it is safe to deallocate the arena. This is less fine-grained than Rust's approa…
Flix has regions which also restrict the scope of certain values. Seems like a similar concept. And D has “scope” and “return scope” to describe when variables are intended to not escape (unless returned in the latter case).
Re: Capture Checking in Scala
#4Meh. Scala's great strength used to be a simple, consistent model instead of zillions of ad-hoc features (e.g. implicits replace maybe 5 or 6 special-case features in other languages). But Scala 3 seems to be determined to destroy that elegance and turn into a pile of special cases. If I wanted that I'd use Kotlin.
Re: Capture Checking in Scala
#5Oh, Scala...I thought the language was practically dead.
Re: Capture Checking in Scala
#6Meh. Scala's great strength used to be a simple, consistent model instead of zillions of ad-hoc features (e.g. implicits replace maybe 5 or 6 special-case features in other languages). But Scala 3 seems to be determined to destroy that elegance and turn into a pile of special cases. If I wanted that I'd use Kotlin.
I would say that having lost the adoption wave, especially since Google got cozy with JetBrains, thus making Kotlin unavoidable on Android, and all big data solutions that were powered by Scala going into modern C++/Go/Rust, eventually the only thing left to keep Scala relevant is to be Haskell on the JVM.
Still, F# could only dream to have half as much adoption as Scala.
Re: Capture Checking in Scala
#7Meh. Scala's great strength used to be a simple, consistent model instead of zillions of ad-hoc features (e.g. implicits replace maybe 5 or 6 special-case features in other languages). But Scala 3 seems to be determined to destroy that elegance and turn into a pile of special cases. If I wanted that I'd use Kotlin.
Strange since Scala’s huge standard library and FP/OO choose-your-own-adventure garnered a ton of criticism as being “too unopinionated” leading to many ways to accomplish the same thing and confusion on what was “blessed”.
If anything Scala 3 was an attempt to standardize and reduce some of the existing complexity to make it more widely appealing.
Re: Capture Checking in Scala
#8Meh. Scala's great strength used to be a simple, consistent model instead of zillions of ad-hoc features (e.g. implicits replace maybe 5 or 6 special-case features in other languages). But Scala 3 seems to be determined to destroy that elegance and turn into a pile of special cases. If I wanted that I'd use Kotlin.
Strange since Scala’s huge standard library and FP/OO choose-your-own-adventure garnered a ton of criticism as being “too unopinionated” leading to many ways to accomplish the same thing and confusion on what was “blessed”. If anything Scala 3 was an attempt to standardize and reduce some of the existing complexity to make it more widely appealing.
> If anything Scala 3 was an attempt to standardize and reduce some of the existing complexity to make it more widely appealing.
I know that's the argument, but I think it ends up the opposite. Splitting one consistent feature into three overlapping subsets is not a simplification in my book - it might make the easy cases slightly easier, but it makes the hard cases much harder.
Re: Capture Checking in Scala
#9Meh. Scala's great strength used to be a simple, consistent model instead of zillions of ad-hoc features (e.g. implicits replace maybe 5 or 6 special-case features in other languages). But Scala 3 seems to be determined to destroy that elegance and turn into a pile of special cases. If I wanted that I'd use Kotlin.
Strange since Scala’s huge standard library and FP/OO choose-your-own-adventure garnered a ton of criticism as being “too unopinionated” leading to many ways to accomplish the same thing and confusion on what was “blessed”. If anything Scala 3 was an attempt to standardize and reduce some of the existing complexity to make it more widely appealing.
What’s the preferred syntax in Scala 3? Python-like indentation based or C-like curly braces? Is FP the “default“ or OOP?
Re: Capture Checking in Scala
#10Nice article. It reminds me of another post a little while ago about OCaml. Like OCaml, Scala is getting more systems programming capabilities. Capture checking can, for example, be used to implement safe memory arenas (aka slab allocation or memory pools.) If you can prove that no code has captured anything from the arena, you can prove it is safe to deallocate the arena. This is less fine-grained than Rust's approa…
Flix has regions which also restrict the scope of certain values. Seems like a similar concept. And D has “scope” and “return scope” to describe when variables are intended to not escape (unless returned in the latter case).
As does C#, after they decided to incorporate Midori learnings, and C++/CLI wasn't going to be cross-platform, so C# needed to improve its low level capabilities.