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?
Yeah, tuples are a builtin type, but there is no module devoted to providing utilities for tuples
just like records/tags are types, but have no dedicated builtin module
oh right
hm where is the compiler logic for them?
i would've thought there's more to it than just the decoding part
like how am i able to index into it?
pattern match?
@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:
Folkert de Vries said:
pattern match?
no i meant direct access like what brendan mentioned
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 accesssomeTuple.0
.A few examples:
thanks!!
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
so instead of needing like a Tuple.snd
or something, you can just have .1
btw so why did you guys decide not to offer mapping functions over tuples?
because elements in a tuple can have different data types?
no I mean like Elm's mapFirst/Second/Both
just doesn't seem worth a whole module, to be honest
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
we could always add syntax sugar for it if it seemed worth it
so tuples ended up not being extensible? (I remember the reasoning was to enable tuple functions that weren't coupled to the tuple arity)
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