As I understand it this is precisely why in Haskell and OCaml standard libraries we get lots of things like
map : (a -> b) -> a list -> b list
instead of
map : a list -> (a -> b) -> b list
The main argument (data to be operated on) is positioned last, after the others which are more like parameters that tune the function.
It's to allow chaining these things up left to right like Unix pipes:
The technique of currying method parameters such that the last one is the input to the operation also makes chaining Kleislis[0] quite nice, albeit using a bind operator (such as `>>=`) instead of the Thrush combinator operator (`|>`).
The point about Rust is to avoid any extra runtime cost by statically enforcing a set of rules (borrow checking) on reference use that are sufficient to guarantee memory safety. It also has ARC but it's reserved only for cases where those rules are too restrictive.
I was actually talking about automatic reference counting. I think both Rc and Arc count as automatic reference counting? It's just that the term (which was apparently coined by Apple?) is not commonly used outside Apple's languages.
I'm not familiar with Swift though so my understanding could be incorrect.
My understanding is that Rust doesn't have _automatic_ reference counting as in Swift only because it has an alternative (move), which requires the programmer to specify their intent. The principle is nevertheless the same: ensure every time a reference is copied the ref count is incremented, free only when ref count is zero, and we get temporal memory safety.
It depends on the context of the code, its after the optimization pass but before emission of LLVM IR, But in most cases it shouldn't be super expensive, the conversion itself happens at compile time, but the usage is at run-time, it can be turned off entirely, but we need testing to see the actual performance implications. Right now the AMT is written down in an internal MD document, we've figured out the whole theory bit, the implantation comes after we written the error-handler (for compiler side error messages), lexer, pre-processor, parser, symbol table, Optimizer passes, Borrow Checking IR (haven't decided a proper name on it yet for now its just BCIR), and then the AMT, followed by the Emitters. Then the rest of the features follow suite. but we will test each stage individually once their complete and have a proper dataset of numbers to see performance memory usage and other metrics, with proper real world cases (it very well may be slower or not, we don't know yet in theory, there's no immense performance implications at runtime other then a a couple ...ns extra).
There are different types of harmonicas. For 10-hole/blues harmonicas bending is a fairly common technique. It's less common or easy to do on other types of harmonicas, eg chromatic harmonicas. Maybe you tried one of those as a kid.
I own a Kindle Oasis 2. Amazon stopped software updates for it so I just jailbroke it and loaded KOReader. It's way better than the official software, probably the most feature-rich and customisable document viewer I've ever seen. I regret not installing it earlier.
I wouldn't call it an entirely new distro. It's just an Fedora image bundled with the necessary changes to create the UX. It doesn't provide its own software repositories. It's more like an unofficial Fedora Spin.
I see, it still seems like the kind of project that would be much better suited to a DE packge-group style release. I think very few people will want to reinstall their OS just to try it.
Essentially turning kwin into a tiling WM