Linear Haskell: practical linearity in a higher-order polymorphic language · HackerPapers discussions

Linear Haskell: practical linearity in a higher-order polymorphic language — mentioned by tome

Thu, 31 Dec 2020 11:30:23 GMT

Good observation. I believe you would use withFADR :: (FragileAndDangerousResource #-> Unrestricted a) -> Unrestricted a One can't tag "linear" values in the type system but one can tag non-linear "unrestricted" values. See "borrow" in Section 7.2, page 5:26 of https://arxiv.org/pdf/1710.09756.pdf

Paper and discussion history. A mention is not an endorsement.

Linear Haskell: practical linearity in a higher-order polymorphic language — mentioned by mauricioc

Wed, 30 Dec 2020 20:49:42 GMT

There is no such thing as a "linear value" per se, since linearity is on the arrow. But speaking of linear values makes sense when there's an ambient monad, and all of the restrictions you expect are enforced; see Section 2.7 (and the last paragraph of Section 6.1) of https://arxiv.org/pdf/1710.09756.pdf for details.

Paper and discussion history. A mention is not an endorsement.

Linear Haskell: practical linearity in a higher-order polymorphic language — mentioned by chrisaycock

Wed, 30 Dec 2020 18:57:29 GMT

I first became fascinated by linear [1] and uniqueness [2] types with Clean [3], a purely functional language that handles state and IO without monads. This Haskell extension uses linear types for resource safety and scoped effects [4]. For example, linear types can prevent use-after-free errors. Also, linear-typed arrays can perform in-place updates if there are no external pointers to the data. Similar to linear types is the affine type, where a value is used at-most once. Rust's borrow checker is based on this notion, so that values are "moved" rather than "copied". [1]…

Paper and discussion history. A mention is not an endorsement.

Linear Haskell: practical linearity in a higher-order polymorphic language — mentioned by pjmlp

Thu, 24 Sep 2020 15:34:38 GMT

Here is one example, https://github.com/rust-lang/rust/issues/63818 Alternative ideas, here are four, combining the productivity of automatic memory management with ownership, https://swift.org/blog/swift-5-exclusivity/ https://github.com/apple/swift/blob/master/docs/OwnershipMan... https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in... "Linear Haskell", https://arxiv.org/abs/1710.09756 In the context of Rust, maybe showing lifetimes graphically in an IDE would help productivity versus languages that offer automatic memory management alongside ownership.

Paper and discussion history. A mention is not an endorsement.

Linear Haskell: practical linearity in a higher-order polymorphic language — mentioned by garmaine

Sun, 03 Feb 2019 06:10:38 GMT

There's a bit more said about it here: https://arxiv.org/pdf/1710.09756.pdf

Paper and discussion history. A mention is not an endorsement.

Linear Haskell: practical linearity in a higher-order polymorphic language — mentioned by T-R

Tue, 09 Oct 2018 08:20:57 GMT

Something to keep in mind - linear types are on their way[1], with exactly this usecase in mind. Simon Peyton Jones gave an excellent presentation on the topic[2], briefly discussing exceptions, as well as giving a mention to ResourceT and the phantom type solution in the article (described as channel-passing). [1] https://arxiv.org/abs/1710.09756 [2] https://www.youtube.com/watch?v=t0mhvd3-60Y

Paper and discussion history. A mention is not an endorsement.

Linear Haskell: practical linearity in a higher-order polymorphic language — HN submission

Thu, 02 Nov 2017 02:11:11 GMT

Linear Haskell: practical linearity in a higher-order polymorphic language

2 points; 0 discussion replies on HN. Paper and source history. A submission is not an endorsement.