FYI, because I know it will be brought up; GHC models linearity differently than Rust, so you can't compare the two against each other, even though you think you would be able to do that.<p>Rust puts linearity on the types, GHC puts linearity on the arrows.<p><a href="https://imgur.com/s0Mxhcr" rel="nofollow">https://imgur.com/s0Mxhcr</a><p><a href="https://skillsmatter.com/skillscasts/11067-keynote-linear-haskell-practical-linearity-in-a-higher-order-polymorphic-language" rel="nofollow">https://skillsmatter.com/skillscasts/11067-keynote-linear-ha...</a>
Are there are books/video lectures that explain linear types how they are useful in a programming language?<p>How do people that don't have PhDs bridge the gap in their knowledge from what's commonly taught/used (OOP and it's design patterns) to thinking in terms of monads/monoids/functors/etc. ?
Besides potentially enabling new types of APIs, I simply like that this extension lets you write more precise type signatures. A function with type [a] %1 -> [a] can do less things that a function with type [a] -> [a].
Can someone explain what this means, practically speaking? I know Haskell fairly well, but am not familiar with linear types. These are types that can be used only once, right?
Any pointers to a comparison between Clean's uniqueness typing and GHC's linear types? And is Rust the motivating factor behind linear types cropping up lately? I see Idris is now getting them as well.
I'm not super well versed on this stuff, but aren't affine types strictly superior? Though I suppose linear types might be better for tracking system resources?
Well. There goes the library ecosystem until everyone finally realizes this extension doesn't do what they want. <i>sigh</i><p>To expand a bit further:<p>This extension allows annotating function types with linearity information. The problem is that those modified function types control what is allowed to happen <i>inside</i> them. They have no impact on how values are used outside them.<p>This is the big difference between linear typing and uniqueness typing. Uniqueness typing lets you say "this function is the only thing using this value."<p>It's possible to use this extension to assemble something sort of like uniqueness, but the ergonomics are pretty awful and no one bothered working through all the ugly details like exception handling in the context of a real application.<p>I really don't believe this is ever going to be better than existing techniques. But it's absolutely going to make the library ecosystem permanently worse, as lots of packages will get linearity annotations added. Lots of forks will arise without them, for the people who don't want the hassle. Finding the library you actually want is just going to get even more complicated.<p>I still don't understand how this happened. Every strong objection was just ignored. What's the point of even having a public comment process when it makes no difference to the outcome?