There's Austral https://austral-lang.org/ for linear types, I'm not sure what is the state of the language but it has a nice tutorial about linear types.
Wow, this really hits the nail on the head for me. I've been pondering about how to make systems that can only be in well-defined states, modified by well-defined state transitions.
This looks like one giant step forward in that direction. I'll be enthusiastically playing around with Austral, all while hoping these concepts can become standardised, and maybe retrofitted to popular tech by way of design patterns or language features, in the future.
This is great, really accessible! I feel like for me the par operation ⅋ is the thing I struggled with getting intuition for the most, and I think that I am (and everyone else is!) still kind of figuring out the consequences of it, and a lot of language designers neglect it.
I didn't know about this! That's brilliant, thank you for the pointer!
Since the death of LtU I don't really know where to learn about interesting new PL work. I try to occasionally read the POPL submissions but there's nothing like HN for PL.
Mojo has some support for Linear Types, it is not fully-fleshed out yet because of missing type system machinery, but the plan is to have full support for Linear Types.
ATS2 has full support for linear and dependent types, capable of operating at pointer-level arithmetics. While the docs may seem impenetrable, in essence it's just a framework of four composable components 1) constrained data types T's, 2) description of resource management and ownership V's, 3) a statically checked "package-deal" (T * V) for lawful programmer-decided ownership semantics (as opposed to "the only true way" in Rust), and 4) formal proofs of the programmed logic. And you are free to mix & match them canteen-style.
Whenever there's a need for complex C API with generics, it's much more pleasant to implement it as a wrapper atop verified ATS C-output rather than C itself.
No. A phantom type is a type whose only use is to communicate a constraint on a type variable, without having a runtime value that corresponds to it.
Typestate is a bit closer: it communicates some property where an operation (typically a method invocation) changes the property and hence the typestate. But there isn't necessarily a mechanism that renders the value in the old typestate inaccessible. When there is, then this indeed requires some linearity/affinity ("consuming the object"), but typestate is something built "on top".
Kind of! Specifically typestates allow you to encode the special case of linear functions `f a ⊸ f b` for some type constructor `f` where `a` and `b` are (usually?) phantom types. Phantom types themselves don't involve any linearity per se though.
There's Austral https://austral-lang.org/ for linear types, I'm not sure what is the state of the language but it has a nice tutorial about linear types.
Wow, this really hits the nail on the head for me. I've been pondering about how to make systems that can only be in well-defined states, modified by well-defined state transitions.
This looks like one giant step forward in that direction. I'll be enthusiastically playing around with Austral, all while hoping these concepts can become standardised, and maybe retrofitted to popular tech by way of design patterns or language features, in the future.
This is great, really accessible! I feel like for me the par operation ⅋ is the thing I struggled with getting intuition for the most, and I think that I am (and everyone else is!) still kind of figuring out the consequences of it, and a lot of language designers neglect it.
Do you know about the Par language? They try to integrate Par into a usable syntax
https://github.com/faiface/par-lang
I didn't know about this! That's brilliant, thank you for the pointer!
Since the death of LtU I don't really know where to learn about interesting new PL work. I try to occasionally read the POPL submissions but there's nothing like HN for PL.
Mojo has some support for Linear Types, it is not fully-fleshed out yet because of missing type system machinery, but the plan is to have full support for Linear Types.
Here is the full proposal: https://gist.github.com/VerdagonModular/9dfc97a3fbed72280019...
ATS2 has full support for linear and dependent types, capable of operating at pointer-level arithmetics. While the docs may seem impenetrable, in essence it's just a framework of four composable components 1) constrained data types T's, 2) description of resource management and ownership V's, 3) a statically checked "package-deal" (T * V) for lawful programmer-decided ownership semantics (as opposed to "the only true way" in Rust), and 4) formal proofs of the programmed logic. And you are free to mix & match them canteen-style.
Whenever there's a need for complex C API with generics, it's much more pleasant to implement it as a wrapper atop verified ATS C-output rather than C itself.
https://ats-lang.sourceforge.net/DOCUMENT/INT2PROGINATS/HTML...
Newb question, aren't phantom types and typestates a subset (or cousin) of linear types ?
No. A phantom type is a type whose only use is to communicate a constraint on a type variable, without having a runtime value that corresponds to it.
Typestate is a bit closer: it communicates some property where an operation (typically a method invocation) changes the property and hence the typestate. But there isn't necessarily a mechanism that renders the value in the old typestate inaccessible. When there is, then this indeed requires some linearity/affinity ("consuming the object"), but typestate is something built "on top".
Thanks a lot
Kind of! Specifically typestates allow you to encode the special case of linear functions `f a ⊸ f b` for some type constructor `f` where `a` and `b` are (usually?) phantom types. Phantom types themselves don't involve any linearity per se though.
Sorry off topic but I love the styling of this site.
Hi! I put a lot of effort into getting it to look just how I like it and I'm very happy you like it too :)