Stream: ideas

Topic: & Pass by reference syntax

Brian Teague (May 03 2025 at 00:59):

This idea is just for increased readability. Would it be nice to require & in front of function types when passing as an argument, so it's obvious they are being passed by reference instead of being called? I guess () already shows a function is being called with or without arguments, but nothing to show a variable function name is being passed by reference?

main! =
    store_email!(Path.from_str("url.txt")) ? &handle_err!

store_email! = |path|
    url = File.read_utf8!(path)?
    user = Http.get!(url, Json.utf8)?
    dest = Path.from_str("${user.name}.txt")
    File.write_utf8!(dest, user.email)?
    Stdout.line!("Wrote email to ${Path.display(dest)}")

handle_err! = |err|
    when err is
        HttpErr(url, _) -> Stderr.line!("Error fetching URL ${url}")
        FileReadErr(path, _) -> Stderr.line!("Error reading from ${Path.display(path)}")
        FileWriteErr(path, _) -> Stderr.line!("Error writing to ${Path.display(path)}")

Brian Teague (May 03 2025 at 01:01):

It also makes it obvious if the variable name is a function, or some other type

Brendan Hansknecht (May 03 2025 at 01:02):

I understand the goal here, but it isn't pass by reference. So I wouldn't call it that.

Brendan Hansknecht (May 03 2025 at 01:02):

It also might be very odd for inline lambdas

Brian Teague (May 03 2025 at 01:03):

(deleted)

Brian Teague (May 03 2025 at 01:03):

I wouldn't think inline needs & because it's not a variable

Brian Teague (May 03 2025 at 01:04):

What is it called when a function is passed in as an argument like List.map for example?

Brendan Hansknecht (May 03 2025 at 01:04):

List.map(list, |x| x + 1)

Brendan Hansknecht (May 03 2025 at 01:04):

That is an inline lambda

Brian Teague (May 03 2025 at 01:05):

addOne = |x| x + 1
List.map(list, &addOne)

Brendan Hansknecht (May 03 2025 at 01:05):

Yeah, those two are exactly the same in roc. So likely they should be treated the same in syntax (but they don't strictly have to be)

Brian Teague (May 03 2025 at 01:06):

Yeah, the & would only be required on variable names with type function.
I think it makes it obvious which arguments for the map function are data types / array / obj vs a function

Brendan Hansknecht (May 03 2025 at 01:06):

Brian Teague said:

What is it called when a function is passed in as an argument like List.map for example?

No special name. Just passing a function. Reference or not is an implementation detail that roc users don't interact with

Brian Teague (May 03 2025 at 01:07):

When I see List.map(list, &addOne) I immediately know addOne is a function without knowing the implementation details for addOne.

Brendan Hansknecht (May 03 2025 at 01:10):

That's fair. I understand the idea. I don't particularly see a reason to make functions special, but I get that they can do more than regular data types. That said, what about a record of functions or a list of functions?

Brendan Hansknecht (May 03 2025 at 01:11):

I guess those would just pass like regular records or lists?

Brendan Hansknecht (May 03 2025 at 01:11):

Cause a record of functions can do a lot more than a single function but is not particularly more special than any other record.

Brian Teague (May 03 2025 at 01:15):

{a: &doStuff, b: anInt} # Obvious a has a function type
vs
{a: doStuff, b: anInt} # current version

&[doStuff1, doStuff2] # arrays have strict types, so maybe only need 1 &
vs
[&doStuff1, &doStuff2] # still like this better
vs
[doStuff1, doStuff2] #current version
vs
[anInt1, anInt2]

(&doStuff, anInt) #tuple example, first arg is a function

Brian Teague (May 03 2025 at 01:17):

Yeah, I think & in front of functions makes it obvious which are functions and which are normal data types.

Brendan Hansknecht (May 03 2025 at 01:18):

Fair enough. I don't particularly find this compelling, but I understand it. Curious to hear other opinions.

To me it is extra noise that I almost never need (but very minor noise)

Brian Teague (May 03 2025 at 01:19):

When learning more complicated functional programming that use functions as arguments, I have thought to myself, "man, I wish I knew that was a function type" ahead of time (mainly in JavaScript)

Brian Teague (May 03 2025 at 01:19):

Devils advocate, I guess the verb in the variable name usually gives that away too.

Brian Teague (May 03 2025 at 01:20):

Humans are very good at pattern recognition.

Brian Teague (May 03 2025 at 01:22):

And this makes it explicitly obvious, () means the variable is being invoked, and & means the function variable is being passed as an argument.

Brian Teague (May 03 2025 at 01:23):

callFunc1(a, b, &c, callFunc2(d, &e))

When looking at this which variables are functions, and which variable are being called, and which variables are values like int, str, array, or obj?

Brian Teague (May 03 2025 at 01:25):

But yeah, the new syntax ROC is currently using is just pure AWESOME!!!

Brendan Hansknecht (May 03 2025 at 01:59):

What if callFunc2 returns a lambda?

Brendan Hansknecht (May 03 2025 at 01:59):

Still same syntax?

Anton (May 03 2025 at 09:27):

In the IDE with type on hover it's pretty easy to see what's a function if it's not already clear from the name.

Anton (May 03 2025 at 09:30):

From my own experience I believe I rarely pass a function that isn't an inline lambda.

Anthony Bullard (May 03 2025 at 09:41):

I think that if we ever introduced a syntax like this, to Anton’s point, it should be for something like partial application - probably for a static dispatch call

Anthony Bullard (May 03 2025 at 09:47):

And to be clear I’m not arguing in favor of us introducing that syntax

Brian Teague (May 03 2025 at 13:37):

Brendan Hansknecht said:

Still same syntax?

That is a really good edge case I did not see. I think & in front of callFunc2 would be useful information to tell the user it returns a function. In this example the function call () still has a higher precedence then &, and & is just informational to show the return type of callFunc2.

callFunc1(a, b, &c, &callFunc2(d, &e))

Brendan Hansknecht (May 03 2025 at 19:45):

Anton said:

In the IDE with type on hover it's pretty easy to see what's a function if it's not already clear from the name.

I'm not for this suggestion, but in general, I don't think that LSPs are enough here if you want a feature like this. The LSP requires interaction to see the info. This is info that @Brian Teague looks to want at a glance. An LSP will not give you that over a larger function. So I think there is a clear distinction here.

Brendan Hansknecht (May 03 2025 at 19:46):

For myself, I think naming is enough general. Also, I am just so familiar with the various functions in my code that take lambdas that none are surprising. I know that map, walk, etc all take a lambda.

Hannes (May 04 2025 at 02:09):

I imagine if Richard's original dream of making the Roc editing experience easily extendable ever comes true it should be possible write a plug-in in Roc to add inlay hints to the IDE that show which values are lambdas. For now you would have to fork a Roc extension to add it.

jan kili (May 05 2025 at 15:45):

Note: Syntax highlighting (such as with Eli's tree-sitter-roc and my rocwise-editor-themes) should color function identifiers with a distinct color, even when referenced in function arguments.

kris (May 06 2025 at 05:15):

"The LSP requires interaction to see the info". This is entierly up to the editor configuration no? Emacs with eglot LSP integration displays type information inline by default in rust for example.

Hannes (May 06 2025 at 06:12):

Yeah that's what I was talking about earlier, vscode calls them "inlay hints"

Krzysztof Skowronek (Jun 26 2025 at 13:46):

IMO this should be LSP function - and let the editor differntiate variables tha hold functions with different colors.

I don't really think having the symbol prefixes for everything is a good idea - it will get annoying to type

In C# we have different colors for local variables, class fields etc - you can take it to the extreme with theming.

Last updated: Jun 16 2026 at 16:19 UTC