static dispatch - tuple accessors and zero-arg functions · ideas

Stream: ideas

Topic: static dispatch - tuple accessors and zero-arg functions

Richard Feldman (Jan 13 2025 at 04:20):

random idea that static dispatch enables (not saying we should or shouldn't do this, just an idea):

replace the current tuple accessors (.0, .1, etc.) with methods (e.g. .get_0(), .get_1(), etc. - or some other name)
make it so that tuples automatically get these methods based on their number of fields (like how we already say various structural types get methods automatically)
this eliminates the need for "open tuples" as a concept in the language, which are only needed in order to allow for inferring a type for |x| x.0 - in the static dispatch world, we already have a type for |x| x.get_0() so that wouldn't need special handling
this in turn means that we no longer need () in the language if we don't want it (we could keep {} as our "unit" type)
this in turn means we could say that () -> Str is actually a zero-arg function, because () is no longer a type (or a value), so it could be used exclusively and unambiguously to mean "a function of zero arguments" - which would have nice symmetry with how they're called, e.g. with foo()

Richard Feldman (Jan 13 2025 at 04:27):

separately (also not saying this part is or isn't a good idea either), that would mean that if we wanted to, we could do the ".( means partial application" idea from #ideas > static dispatch - partial application syntax by having "partially applied function" be a valid type (since that requires having a first-class concept of 0-arg functions)

Sam Mohr (Jan 13 2025 at 04:27):

If this means I can stop working on fixing mono bugs with (), I'm here for it /s

Sam Mohr (Jan 13 2025 at 04:28):

I really think having zero-arg functions is a must-have for Roc

Richard Feldman (Jan 13 2025 at 04:28):

it definitely is the most obvious design

Sam Mohr (Jan 13 2025 at 04:28):

And parens make a lot of sense for notating functions

Sam Mohr (Jan 13 2025 at 04:28):

Tuples aren't that important in the scheme of things

Sam Mohr (Jan 13 2025 at 04:29):

So if we can make them usable in some other way such that parens can handle arg notation, then Roc looks more consistent and we don't have to use 3 different kinds of syntax sugar as a stopgap

Richard Feldman (Jan 13 2025 at 04:29):

well as discussed in #ideas > ✔ Do we need tuples? they're important enough to be worth having in the language, and it's frequently annoying if the only way to get values out of them is to destructure them :sweat_smile:

Sam Mohr (Jan 13 2025 at 04:29):

I'm all in on this

Richard Feldman (Jan 13 2025 at 04:29):

but yeah, static dispatch means we can simplify them I think

Sam Mohr (Jan 13 2025 at 04:29):

Yes, we need them

Sam Mohr (Jan 13 2025 at 04:30):

I really like the idea of types and values looking more similar

Sam Mohr (Jan 13 2025 at 04:32):

get_results! : () => Result(List(U64), LoadErr)
read_file! = ||
    res = load_results!()?
    Ok(res.transform())

Sam Mohr (Jan 13 2025 at 04:32):

That's not explicitly proposed here

Sam Mohr (Jan 13 2025 at 04:33):

Though this moves us in that direction

Richard Feldman (Jan 13 2025 at 04:33):

ah, I think someone brought that up at some point

Sam Mohr (Jan 13 2025 at 04:34):

Yep, let me find the thread

Richard Feldman (Jan 13 2025 at 04:34):

I don't have strong feelings about it (both ways look fine to me), but feel free to start an #ideas thread on it!

Richard Feldman (Jan 13 2025 at 04:36):

I know List<U64> is the most mainstream, but I do think that looks significantly worse than either (List U64) or List(U64), especially once you end up in >>> territory

Sam Mohr (Jan 13 2025 at 04:36):

Yep, I'd be pushing for List(U64)

Richard Feldman (Jan 13 2025 at 04:36):

Scala uses List[U64] as I recall, but we already use [ ] for something else

Sam Mohr (Jan 13 2025 at 04:36):

That's how tags work now anyways

Richard Feldman (Jan 13 2025 at 04:36):

looks like Gleam uses List(U64)

Sam Mohr (Jan 13 2025 at 04:36):

So it's just an extension of that

Richard Feldman (Jan 13 2025 at 04:37):

so maybe we could see how Gleam folks feel about it in practice? I don't know of any other languages which use that syntax

Sam Mohr (Jan 13 2025 at 04:37):

They have a Discord, or we could ask here?

Sam Mohr (Jan 13 2025 at 04:37):

I'll start that thread, anyhow

Richard Feldman (Jan 13 2025 at 04:38):

good to get these things sorted out one way or the other prior to 0.1.0 :big_smile:

Sam Mohr (Jan 13 2025 at 04:39):

Yep, I guess Syntax Season just got Punxsutawney Phil'ed!

Richard Feldman (Jan 13 2025 at 04:39):

there's no :groundhog: so I guess :hedgehog: will have to do

Brendan Hansknecht (Jan 13 2025 at 04:43):

This sounds reasonable. I honestly feel like tuples are less important than originally proposed:

They don't solve the lack of arrays. It is still nicer to use a list than a tuple most of the time. Still can be a win for like a Vec3 type, but isn't a win for a Matrix type. (And you can't use them to make any sort of generic or flexible matrix)
They easily can be replaced with records and probably should be in a number of cases.

I still think they are pretty fundamental for returning multiple things and certain cases where records are too verbose, but otherwise, I feel like they don't add value to the language.

Richard Feldman (Jan 13 2025 at 05:37):

another neat thing: we could automatically give tuples .map_0() and .map_1() as well - I've used things like Tuple.mapFirst in Elm before

Anthony Bullard (Jan 13 2025 at 14:22):

Just a question since there is renewed scrutiny around SD (and we don't know how it will go eventually anyway), but regardless of what happens - it still makes sense for a language with effectual functions to allow effectual functions to have zero args - and therefore a way to annotate that, correct?

Richard Feldman (Jan 13 2025 at 14:38):

I agree, yeah

Oskar Hahn (Jan 15 2025 at 07:50):

Have you talked about allowing multiple return values? If the main reason for tuples is returning multiple values, then maybe supporting it directly is even better.

I really hate, that zig does not support multiple return values. Multiple return values is an important feature to support webassembly. There are things, in the webassembly world, that zig does not support because of this. They have an issue where there discuss to support it.

I don't think that the c-abi is a problem. This could only be a problem for functions provided by the platform to the host or effects defined by the platform. App code does not have to support c-abi. A platform knows, which abi it wants to support. If a platform wants to return multiple values to the host with c-abi, it can do it in a record, which has (nearly) the same memory layout then tuples. (Records order the fields, so it would not be possible to create a type like (U8, U64) .)

I don't say, that tuples should be removed from Roc. I want to say, that multiple return values is not a strong argument to keep them. I made the experience, that records are superior to tuples and the only reason I use tuples is because I am lazy.

Sam Mohr (Jan 15 2025 at 07:53):

From Richard's recent thread in #ideas > Result.map_ok, here are two code examples showing the difference between tuples and records:

without tuples

params : Request -> List (Str, Str)
params = |req|
    req
    .path()
    .split_first("?")
    .map_ok(.after)
    .with_default("")
    .split_on("&")
    .map(|param|
        when param.split_first("=") is
            Ok({ before, after }) -> (before, after)
            Err(NotFound) -> (param, "")
    )

with tuples

params : Request -> List (Str, Str)
params = |req|
    req
    .path()
    .split_first("?")
    .map_ok(.get_1())
    .with_default("")
    .split_on("&")
    .map(|param| param.split_first("=") ?? (param, ""))

For those APIs where the output values are made obvious by the function name and return type, tuples are less noisy.

Sam Mohr (Jan 15 2025 at 07:55):

So as you probably agree, something like tuples should probably remain in Roc, though I'm with you that records are always more descriptive

Sam Mohr (Jan 15 2025 at 07:55):

But I think you're right that we should consider allowing multiple return values in place of tuples, even after all the discussion we've had on the subject

Sam Mohr (Jan 15 2025 at 07:56):

Tuples seem good for:

grouping values in a low-noise fashion for small handoffs, like as a return from a function of two values, or passing a pair of variables to a when expression
Doing math with something that looks like an array

Sam Mohr (Jan 15 2025 at 07:58):

I think if we supported arrays in Roc, then all of a sudden tuples are much closer to a full type system feature that could instead be a syntax nicety

Sam Mohr (Jan 15 2025 at 07:59):

However, I don't know how to support something like

when (left, right) is
    (Blue, Green) -> ...

without adding lots of little tools that the singular addition of tuples doesn't handle

Brendan Hansknecht (Jan 15 2025 at 22:08):

Sam Mohr said:

Tuples seem good for:

Doing math with something that looks like an array

This almost never happens in practice. I think it is too niche/unergonomic to really be consider a benefit.

I do totally agree they are awesome for multiple return values and pattern matching.

Last updated: Jun 16 2026 at 16:19 UTC