Stream: contributing

Topic: tuples on roc-for-elm-programmers


view this post on Zulip dank (Mar 26 2023 at 07:24):

https://github.com/roc-lang/roc/blob/main/roc-for-elm-programmers.md#standard-library
i went through this just to see if i missed something that wasn't in the tutorial i should know about

the part about tuples seemed outdated so thought i'd quickly update it
but then i had a look, https://github.com/roc-lang/roc/tree/main/crates/compiler/builtins
i see tuple is not implemented like the rest of the builtins
i found a decoding module of it but not sure how it's actually implemented

so it's partly the case that roc does have tuples, but does not expose a Tuple module
how does that work?

view this post on Zulip Ayaz Hafiz (Mar 26 2023 at 14:05):

Yeah, tuples are a builtin type, but there is no module devoted to providing utilities for tuples

view this post on Zulip Ayaz Hafiz (Mar 26 2023 at 14:05):

just like records/tags are types, but have no dedicated builtin module

view this post on Zulip dank (Mar 26 2023 at 14:43):

oh right
hm where is the compiler logic for them?
i would've thought there's more to it than just the decoding part

view this post on Zulip dank (Mar 26 2023 at 14:46):

like how am i able to index into it?

view this post on Zulip Folkert de Vries (Mar 26 2023 at 15:09):

pattern match?

view this post on Zulip Brendan Hansknecht (Mar 26 2023 at 15:53):

@dank , There are a lot of references to tuples directly in the IR. That is how we get both destucturing (a, b) = someTuple and direct access someTuple.0.

A few examples:

view this post on Zulip dank (Mar 26 2023 at 15:56):

Folkert de Vries said:

pattern match?

no i meant direct access like what brendan mentioned

view this post on Zulip dank (Mar 26 2023 at 15:56):

Brendan Hansknecht said:

dank , There are a lot of references to tuples directly in the IR. That is how we get both destucturing (a, b) = someTuple and direct access someTuple.0.

A few examples:

thanks!!

view this post on Zulip Richard Feldman (Mar 26 2023 at 17:38):

yeah the idea is that, like records and tag unions, we shouldn't need a module because there's enough built-in syntax that you don't really need it

view this post on Zulip Richard Feldman (Mar 26 2023 at 17:38):

so instead of needing like a Tuple.snd or something, you can just have .1

view this post on Zulip dank (Mar 27 2023 at 09:17):

btw so why did you guys decide not to offer mapping functions over tuples?

view this post on Zulip Ron Panduwana (Mar 27 2023 at 09:21):

because elements in a tuple can have different data types?

view this post on Zulip dank (Mar 27 2023 at 09:22):

no I mean like Elm's mapFirst/Second/Both

view this post on Zulip Richard Feldman (Mar 27 2023 at 13:46):

just doesn't seem worth a whole module, to be honest

view this post on Zulip Richard Feldman (Mar 27 2023 at 13:46):

especially considering you have to implement a separate one for each arity of tuple, which means you have to decide where to draw the line on what arity to support

view this post on Zulip Richard Feldman (Mar 27 2023 at 13:46):

we could always add syntax sugar for it if it seemed worth it

view this post on Zulip Georges Boris (Mar 30 2023 at 09:12):

so tuples ended up not being extensible? (I remember the reasoning was to enable tuple functions that weren't coupled to the tuple arity)

view this post on Zulip Ayaz Hafiz (Mar 30 2023 at 12:50):

They are extensible- you can define a “fst” function that unpacks the first element of any size tuple


Last updated: Jul 06 2025 at 12:14 UTC