
Linear types can change the world (1990) [pdf] - adamnemecek
http://www.cs.ioc.ee/ewscs/2010/mycroft/linear-2up.pdf
======
danharaj
GHC might get linear types:
[https://ghc.haskell.org/trac/ghc/wiki/LinearTypes](https://ghc.haskell.org/trac/ghc/wiki/LinearTypes)

~~~
johnbender
Linear Haskell: Practical Linearity in a Higher-Order Polymorphic Language [1]

I'm going to see the talk tomorrow at POPL, should be good.

[1] [https://hal.archives-
ouvertes.fr/hal-01673536/file/Linear%20...](https://hal.archives-
ouvertes.fr/hal-01673536/file/Linear%20Haskell%20practical%20linearity%20in%20a%20higher-
order%20polymorphic%20language.pdf)

~~~
danharaj
To be honest I'm not very enthused about the way linear types are being added
to Haskell. I think linear logic has a lot of potential to drastically change
the way we approach programming and I'm not so interested in marginal
improvements to current languages. I really like this paper [0] as an example
of where we could be going. Note that the author is also part of the
initiative to add linear types to GHC.

[0] [http://assert-
false.net/arnaud/papers/A%20dissection%20of%20...](http://assert-
false.net/arnaud/papers/A%20dissection%20of%20L.pdf)

~~~
runeks
What’s the essential difference between the approach described in the linked
paper, and the one Haskell is taking? And what makes you favor the former?

~~~
danharaj
In System L the evaluation contexts are first class and treated symmetrically
with values. This goes beyond the functional paradigm. The Haskell proposal
seeks to implement functional aspect of linear logic.

------
KirinDave
Any discussion of Uniqueness or Linear types deserves a shoutout to Pony,
which like Rust is built around the principle but in a really delightful way.

~~~
steveklabnik
Also
[https://en.wikipedia.org/wiki/Clean_(programming_language)](https://en.wikipedia.org/wiki/Clean_\(programming_language\))

------
geokon
What's a good language to try this out?

From the first few pages it seems to be really workable. I could see a good
chunk of tailrecursive algorithms map neatly to constraints like nocopy and
nodestroy

I'm no programming language nut, but it seems to me that in general if you
have the language semantics to be able to explicitly narrow the capability of
a structure it should lead to improvements when compiling (types in general do
that as well). I remember playing around with ATS a little and it put a smile
on my face that you could explicitly state that a function is tailrecursive,
or mutually tailrecursive with another function. The other end of the spectrum
is something like Scheme where it's not even clear from the semantics if
you're capturing an environment or not! :) (which I still love and is really
handy for writing stuff quick and simple, but I have no clue how a compiler
has to work with that! No guarantees on mutability, stack size etc etc) ATS
also is supposed to have linear types... so maybe I should revisit it some
time

~~~
navaati
Rust is pretty much based around linear types (well I think technically it's a
variant of that, I have heard about "affine types", don't know the
difference), more precisely the move semantics.

EDIT: Oh, the expert has spoken while I was writing. See steveklabnic's answer
!

~~~
lmkg
> I have heard about "affine types", don't know the difference

A value with a linear type is used _exactly_ once. A value with an affine type
is used _at most_ once. In other words, both types prevent double-use of
single-use resources, but linear types additionally guarantee no leaks of said
resources.

True linear types are far less common in practice, because in order to prove
that a value is actually consumed, you have to prove that the program doesn't
go into an infinite loop first. Which, y'know, good luck with that.

~~~
bjz_
> Which, y'know, good luck with that.

Most dependent type systems like Agda, Coq, Idris, Lean, and ATS have
termination checking, so it is possible! They can't determine whether
arbitrary programs terminate, but you can capture a large subset of programs.
Turns out most code doesn't actually need Turing completeness.

~~~
noblethrasher
Since I've started paying attention, I've noticed that most of the code I
write doesn't need anything more powerful than _formal_ regular expressions,
and vanishingly rarely needs to go beyond deterministic context-free.

~~~
geokon
Now you've got me curious :) Could you give some examples? I've never come
across regular expressions outside of string handling

------
qznc
Their siblings, affine types, change the world in the form of Rust. ;)

~~~
sprt
Relevant:
[https://hyper.rs/hyper/v0.9.6/hyper/client/request/struct.Re...](https://hyper.rs/hyper/v0.9.6/hyper/client/request/struct.Request.html)

~~~
tomjakubowski
Could you elaborate? There isn’t much of a discussion there of the benefits
from making Request affine.

~~~
carry_bit
headers_mut is only defined on Request<Fresh>, and you can only write body
data using Request<Streaming>. This makes it so it's a type error to try to
modify the headers after you already sent them.

------
macawfish
Is this about organizing side-effects in a way that compilers can optimize?

~~~
bsaul
I asked myself a bit of a related question. Is this theory related to
[https://en.m.wikipedia.org/wiki/Static_single_assignment_for...](https://en.m.wikipedia.org/wiki/Static_single_assignment_form)
?

~~~
jw-
I think SSA is related to CPS, but I'm not sure of the correspondence with
Linearity. I think the key difference (but I'm not sure), is that SSA only
asserts that a variable is assigned once, but might be consumed multiple
times. Linearity says that things must be consumed exactly once. For instance,
I think:

y <\- x + 1

z <\- x + 2

is a legal SSA expression, but it is not a legal linear expression because x
appears twice.

(Corrections welcome)

------
amenghra
It’s always fun to look at the flow of knowledge from academia to the
industry, and how some things can take decades.

Reminds me of LinearML which was an experiment nearly 10 years ago.

[https://github.com/pikatchu/LinearML/blob/b1a49f153e02f3cffb...](https://github.com/pikatchu/LinearML/blob/b1a49f153e02f3cffb32784f2eeb7fca017b2791/README)

------
moocowtruck
After 17 years I think we can say they did not change the world!

~~~
bsaul
Add 10 more years :)

~~~
moocowtruck
lol ok we'll check back then, you and i

edit: haha!! just got what you said and realized my mistake :o

------
AstralStorm
So, why haven't they yet as 25 years have passed?

It is nor like they are hard or expensive to implement, more like nobody cares
and the claim is overblown. Most mistakes in software are in boundary
conditions nowadays and not invalid type handling.

Enforcing immutability is great until you get to deal with big number of
additional values of immutable types because you cannot modify them. Easy to
reason about, bad for performance.

~~~
kbr
Linear types are different from immutable types. You can change the value of a
linear type as long as you used the previous value somewhere else (for example
i = i + 1). Languages like Rust leverage affine types (another substructural
type system similar to linear type systems) in order to guarantee memory
safety.

