Changing order of labels in a function call does not change order of evaluation.

[hayleigh-dot-dev]

I've noticed that when using labels in a function call, the order arguments are evaulated in does not correspond to the order written in the source code. Instead, the arguments are evaluated in the order they are defined in the function itself.

I have this function:

pub fn fit(into viewport: Bounds, box box: Bounds) -> Transform

You can see it has two arguments, labelled into: and box: respectively. If we take this call:

transform.fit(
  into: echo bounds.new(..) as "viewport",
  box: echo graph.fold(..) as "box",
)

and look at the console output, we can see:

[Log] dev/experiments/layout.gleam:40 viewport (layout.mjs, line 246)
#(0, 0, 300, 300)

[Log] dev/experiments/layout.gleam:41 box (layout.mjs, line 246)
#(0, 0, 293.48392537260776, 291.62981208738245)

All is expected. "viewport" is logged first, then "box".

However, if we flip the order we provide the labels, so now the function call is:

transform.fit(
  box: echo graph.fold(..) as "box",
  into: echo bounds.new(..) as "viewport",
)

We can see the that the logs have not changed, and "viewport" is still logged first.

[Log] dev/experiments/layout.gleam:51 viewport (layout.mjs, line 246)
#(0, 0, 300, 300)

[Log] dev/experiments/layout.gleam:40 box (layout.mjs, line 246)
#(0, 0, 293.48392537260776, 291.62981208738245)

Is this a bug? It is very surprising that side effects can happen in a different order to the one provided in the source code!

[giacomocavalieri]

A small reproduction:

pub fn main() {
  wibble(b: io.println("bbb"), a: io.println("aaa"))
}

fn wibble(a _a, b _b) { Nil }

This will print "aaa" first and "bbb" second. The generated code calls the function with the function arguments in the order with which they're defined, not the order in which they're passed. This happens on both targets

export function main() {
  return wibble($io.println("aaa"), $io.println("bbb"));
}

main() ->
    wibble(
        gleam_stdlib:println(<<"aaa"/utf8>>),
        gleam_stdlib:println(<<"bbb"/utf8>>)
    ).

I can work on this!

[lpil]

Huh! I thought we had and fixed this bug a long time ago. Thanks for the report Hayleigh!

[michallepicki]

This may be relevant: AFAIK Erlang does not guarantee left-to-right evaluation order of function arguments (I had a discussion about this somewhere else but now I quickly found another discussion about this on erlangforums that also confirms my recollection)

[hayleigh-dot-dev]

In Gleam it is guaranteed. If some hypothetical point in the future the BEAM undid their change switched back to right-to-left eval Gleam would have to make sure the generated code had left-to-right semantics.