Stream: ideas

Topic: Ensure Unique


view this post on Zulip Brendan Hansknecht (Apr 03 2022 at 15:26):

Should Roc have some sort of annotation to require that some piece of data is unique? It could be at the variable level, the function input level, or potentially the data type level.

Given the compiler depends on uniqueness for optimizations, an annotation of this type would be a good way for a programmer to ensure they don't unintentionally incur the cost of copying the data around. Maybe a model would be super expensive to copy and the programmer wants to guarantee that in release builds it is never copied around.

Thoughts?

view this post on Zulip Brian Carroll (Apr 03 2022 at 15:42):

The type system version of this is called "linear types". I don't know a huge amount about it but I know that it's a well-studied thing, and of course Haskell has it, because Haskell has all of the type things.

view this post on Zulip Brian Carroll (Apr 03 2022 at 15:42):

It seems to me that something like this can't really be separate from the type system though. Applying a uniqueness constraint to a variable or function sounds to me like modifying its type, even if you use different words to describe it!

view this post on Zulip Brian Carroll (Apr 03 2022 at 15:44):

Oh and Rust has a version of it too. The main constraint on "mutable references" is that they're unique.

view this post on Zulip Brian Carroll (Apr 03 2022 at 15:46):

I believe that's implemented using the "linear types" idea.

view this post on Zulip Brendan Hansknecht (Apr 03 2022 at 15:49):

Yeah I guess a full implementation would require linear types. I was thinking it might be possible to be simpler and just look at the uniqueness information we get from morphic

view this post on Zulip Kesanov (Apr 03 2022 at 16:50):

data type level.

I know that Richard wants full type inference, which goes against this.
But perhaps it is fine to force users to manually specify types, if they want absolute performance control?

view this post on Zulip Brendan Hansknecht (Apr 03 2022 at 17:08):

Would this go against fully type inference?

By default we infer not guaranteed unique which is always correct. If specified as unique it propagates and fails to type check if it wouldn't be unique.

view this post on Zulip Brendan Hansknecht (Apr 03 2022 at 17:12):

So, I guess I am just looking at it as an optimization.

view this post on Zulip Folkert de Vries (Apr 03 2022 at 19:21):

there is an existing idea to tie it into the expect syntax

view this post on Zulip Brendan Hansknecht (Apr 03 2022 at 20:25):

So be able to expect that a value is unique. I assume that would be a runtime check in dev and compile time check in release?

view this post on Zulip Ed Kelly (Apr 04 2022 at 12:45):

Brian Carroll said:

The type system version of this is called "linear types". I don't know a huge amount about it but I know that it's a well-studied thing, and of course Haskell has it, because Haskell has all of the type things.

I just read a paper about linearity and uniqueness, which was a unique experience for me because I think I actually understood some of it: https://link.springer.com/content/pdf/10.1007/978-3-030-99336-8_13.pdf.

In particular Section 2.1 is really well-written and explains a subtle difference between linear types and unique types. My takeaway from it was: you can convert an unrestricted type into a linear type, but once a type is made linear it can never be unrestricted again. With unique types it's the opposite: you can convert a unique type into an unrestricted type, but an unrestricted type can never be made into a unique type.

Not sure if this is relevant to uniqueness in Roc, but I thought it was really interesting.

view this post on Zulip Folkert de Vries (Apr 04 2022 at 12:47):

it makes sense to think of uniqueness as something that is lost (because of the context)

view this post on Zulip Folkert de Vries (Apr 04 2022 at 12:47):

and indeed there is no way to "just" regain it

view this post on Zulip Folkert de Vries (Apr 04 2022 at 12:48):

you can essentially clone a value and get uniqueness of that cloned value

view this post on Zulip Richard Feldman (Apr 09 2022 at 02:12):

interestingly, it looks like the authors of Perceus are working on this:

https://koka-lang.github.io/koka/doc/book.html#sec-fbip

In particular we'd like to add ways to add annotations to ensure reuse is taking place.

view this post on Zulip Ayaz Hafiz (Apr 09 2022 at 04:49):

AFAIU they designed perceus specifically for Koka


Last updated: Jun 16 2026 at 16:19 UTC