Interview about Austral, a systems programming language with linear types
blog.lambdaclass.com
blog.lambdaclass.com
A random part of interest: I followed the link about how linear types and exceptions don’t mix: https://borretti.me/article/linear-types-exceptions In it, the author explains how linear types always need to be explicitly destroyed, and if you end up in a “catch” block, you can’t easily go back and destroy things that are now out of scope, which control flow got interrupted while doing things with. “Why not just destroy things when they go out of scope?” I thought. The author addresses this, saying that types that you have to “consume” “at most once” are called affine types, and the compiler can clean them up for you, and it solves the problem with exceptions. Rust has affine types, and you don’t have to explicitly “destruct” every string/object/resource using the appropriate destructor for that type, manually, as you do with linear types (of course, the compiler will make sure you do it, but you have to do it).
So why does Austral use linear types, not affine types? The reasons given do not really resonate with me (but I’m not a systems programmer); it’s that the compiler would have to insert hidden function calls, and secondarily, for temporary/intermediate values, the order of invocation might not be obvious; plus, maybe the programmer not doing something with a value is a mistake. I’m really glad the reasons are written out, however.
In other areas I feel very aligned with the author, such as on the value of required type annotations and local inference rather than global inference, and I’ve saved the link to refer back to the way the opinion is stated.
Because linear types are simpler. The major reason here is that you don't need a "fancy" inference engine of lifetimes like the Rust borrow checker.
(In fact Austral includes a region/borrowing system as well! It is a bit more explicit than Rust, along the lines of Rust's pre-NLL borrow checker, and with concrete binding forms instead of inference for regions, but this is also unrelated to the affine/linear distinction.)
One reason for linear types over automatic scope-based destruction is that the final destruction can take arguments and produce results in a more streamlined way. This is nice for e.g. handling errors on file close.
Couldn't the language allow something like Zig's `defer` op except tie that explicit destructor to the type?
I'm not sure what you mean exactly by "tie to the type," though? Just some kind of standard name for it? The benefit of linearity here is that you can change its signature while still getting the compiler to enforce its usage, so you probably wouldn't want it to look like e.g. Rust's Drop trait.
https://borretti.me/article/how-australs-linear-type-checker...
I was seeing linear types as a kind of: manual ssa + definite assignment analysis + unused variable analysis with the goal to facilitate some typestate analysis by the compiler.
I know barely anything on the subject, just wondering.
At their core, the definition of linear and affine type systems don't reference SSA or dataflow analysis either. Type systems are generally described using the notation of logic (see this intro if you're unfamiliar: https://langdev.stackexchange.com/a/2693/910), and then to get linearity you define the inference rules such that a use of a resource removes it from the context (one way to write this: https://plato.stanford.edu/entries/logic-linear/#SeqCal).
Things like definite assignment are more user-facing convenience features that are also built on top of the core linear logic.
Seems to me, perhaps wrongly, that since there is no aliasing and values are always used, once a value is not returned by a function to be consumed, it's lifetime has effectively ended. So it's automatic?
The point I was making about ssa, dfa, etc. was that it was putting these aspects into userland via the type system.
Do they look simpler in cheesy anecdotes? Sure.
But again, graphs and linked structures come in the to fray and it’s immediately noticeable that there’s be some problems here. Or maybe I am crazy in thinking that “being forced to update every single link just cause one node updated” is a problem.
Even if this is only superficial, I foresee there being not insignificantly annoying issues in how one needs to manage graph and linked structures.
> Is it simple? Yes: the type system rules fit in a napkin. There’s no need to use an SMT solver, or to prove theorems about the code, or do symbolic execution and explore the state space of the program. The linearity checks are simple: we go over the code and count the number of times a variable appears, taking care to handle loops and if statements correctly. And also we ensure that linear values can’t be discarded silently.
https://austral-lang.org/spec/spec.html#rationale-linear-typ...
Affine is fine if there's a catch all operation available for when the value drops out of scope which the compiler inserts. You can call deallocate or similar when an exception comes through the call stack.
If the final operation is some function that returns something significant, takes extra arguments, interacts with the rest of the program in some sort of must-happen sense, then calling a destructor implicitly doesn't cover it.
There's some interesting ideas around associating handlers with functions to deal with exceptions passing through but I think I've only seen that in one language. The simple/easy approach is to accept that exceptions and linear types are inconsistent.
I think linear types and exceptions can play well together if you use controlled effects like this.
This means both paths must use the same set of resources, and exactly one of them must be invoked. Interestingly, in linear logic this is equivalent (using De Morgan dualities) to a single continuation that expects a sum type: A^⊥ & B^⊥ = (A ⊕ B)^⊥.
The happy case is you have an instance of a linear type, you call some unrelated function which doesn't use that instance, then lexically later in the caller you do something with it. All typechecks easily, all is well.
If that unrelated function wants to throw an exception, reinstate some other continuation, or in any other way not execute the use of the instance after said function call, you have a design puzzle.
Affine types solve it by saying the object didn't need to be used anyway, so whatever. No type problems. Whatever deals with garbage collection will handle it.
Linear type systems usually solve it by refusing to let the called function branch to somewhere other than the nominal return site, aka no call/cc or exceptions in the language. Possibly function colouring to say no call/cc or exceptions in anything branched to within the lifetime of a linear variable.
The obvious answer to a compiler dev is that call/return is sugar anyway - all the variables "live across a call site" are implicitly arguments to the branch, so they're available tn whatever continuation the callee invokes. The plumbing is all fine. Typechecking is abstract interpretation so that's all good too, one can totally build the thing.
The missing piece is how you get the programmer to describe what they intend to happen to the linear instance on any continuations which are not the one denoted by the code immediately lexically after the function call 'instruction'. Where the syntax in question is an exception, it means "branch to somewhere implicitly recorded in a side table", so for the linear type use to work out you need to somehow annotate what is supposed to happen to the thing in that case. I don't know of a good notation for that.
(functions taking sum types are prone to being implemented as a branch on which field as active so you're definitely right that success+failure continuations can be transformed into one taking a sum - it's a reversible transform - but I don't think it helps the notation challenge).
But in fact we also have multiple options on the more programmer-familiar side of this- `try/finally` blocks, `defer`, etc. The problem isn't limited to linear types so it's already been pretty thoroughly explored.
Affine types give a safety guarantee: you can't use it more than once. The bad thing (double free, use after free) does not happen.
Linear types give that same safety guarantee, plus a liveness guarantee: you must use it, possibly in some nontrivial way.
A function that takes an affine value as an argument is enforcing a contract about the past behaviour of the caller, leading up to the call: having the affine value is proof that certain other functions were called in the right way to produce it. But returning an affine value gives you weaker guarantees about future behaviour, because you can use it zero times. At most you know that it will get Dropped. But maybe you want to enforce more interesting things than the Drop trait can express. Returning a linear value lets you do this: maybe the linear Foo you return can only be disposed of in conjunction with a linear Bar, like
fn consume(x: Foo, y: Bar) -> Baz
fn drop(x: Foo) -> Unit
Austral Programming Language - https://news.ycombinator.com/item?id=36898612 - July 2023 (118 comments)
What Austral proves - https://news.ycombinator.com/item?id=34845895 - Feb 2023 (21 comments)
Austral: A systems language with linear types and capabilities - https://news.ycombinator.com/item?id=34168452 - Dec 2022 (120 comments)
This is wrong, the notion of modules predated the units from UCSD Pascal units.
https://en.m.wikipedia.org/wiki/Modular_programming
I would assume an interview would do proper fact checking.
They become distinct, and sort of dual to each other, when you relax this restriction: linearity ensures that no copies or aliases are produced going forward, while uniqueness ensures that no copies or aliases have ever been produced in the past.
In other words, if you call a function that is linear in its parameter, you know it won't form any additional copies of the argument, but the function can't assume it has the only reference to that argument, so it can't e.g. update it destructively. Conversely, a function that takes a unique parameter can make that assumption, but its caller can no longer assume that the argument it passed in is unique.
See also this recent paper on the two: https://granule-project.github.io/papers/esop22-paper.pdf
Can I get a cliff notes on what this is doing to solve some pinch point that Rust isn't?
There is also a subset of developers (typically those used to the control of C and/or in the extremes of fault taulerance) that don't want the hiden control flow of implicit Drop / RAII so Linear types offers an alternative.
Personally, I'd also like a best-effort linear types so I can catch errors from closing file handles open for write. I can manually close to get the error but I want help to ensure I do it.
I'll bite: why can't pragmatism feel when it's hitting the diminishing returns curve and, you know, fight for a modicum of principle?
That is: pragmatic pragmatism should fall short of dogmatism.