Stream: ideas

Topic: syntax for `x = f x` pattern


view this post on Zulip Richard Feldman (May 04 2023 at 00:18):

this article by @matklad gave me a random idea I wanted to write down (I'm not actually proposing it per se, just think it's an interesting idea):

view this post on Zulip Richard Feldman (May 04 2023 at 00:20):

something we've talked about before as a motivation for shadowing (e.g. in #ideas > Shadowing & Redeclaration) is this pattern, which comes up sometimes:

\list ->
    list2 = List.set list index1 "blah"
    list3 = List.set list2 index2 "blah"

    List.set list3 index3 "blah"

view this post on Zulip Richard Feldman (May 04 2023 at 00:20):

so the idea is to have syntax sugar for this pattern, such that you could write this:

\list ->
    List.set! list index1 "blah"
    List.set! list index2 "blah"

    List.set list index3 "blah"

view this post on Zulip Richard Feldman (May 04 2023 at 00:21):

in general the pattern would be: fn! x arg2 arg3 desugars to x = fn x arg2 arg3

view this post on Zulip Richard Feldman (May 04 2023 at 00:22):

so to use it, you would have to call the function passing only an identifier (e.g. x or list) as its first argument; otherwise, syntax error

view this post on Zulip Richard Feldman (May 04 2023 at 00:22):

and then that identifier would be assigned to the value returned by the function call

view this post on Zulip Richard Feldman (May 04 2023 at 00:23):

an interesting question is: does this still have the downsides of general shadowing?

view this post on Zulip Richard Feldman (May 04 2023 at 00:24):

I haven't really thought about it (this is just an idle thought I'm sharing because I think it's interesting) but it seems like it probably has some of the downsides but not all of the downsides, because it's a limited form of it

view this post on Zulip Richard Feldman (May 04 2023 at 00:28):

some things I think are interesting about the idea:

view this post on Zulip Richard Feldman (May 04 2023 at 00:29):

I haven't given any serious thought to whether it might actually a good idea in Roc, but I do think it's interesting to think about at least!

view this post on Zulip Richard Feldman (May 04 2023 at 00:30):

a downside that comes to mind is that it could be confusing from a performance perspective, because it looks like it's mutating in-place but really that's not a guarantee

view this post on Zulip Ajai Nelson (May 04 2023 at 01:00):

My first thought is that if I understand right, this syntax sugar wouldn't be much more flexible than pipelining, since it only allows the x = f x ... pattern. This wouldn't allow you to rewrite y = f x y or {x, a} = f x. For example, would there any way to use this syntax sugar for the example given in the thread linked above?

toIdParserList : IdBindState, List Parser -> { state : IdBindState, ids : List Id }
toIdParserList = \state, parsers ->
    List.walk parsers { state, ids: [] } \{ state: state2, ids }, parser ->
        { state: newState2, id } = toIdParser state parser
        { state: newState2, ids: List.append ids id }

view this post on Zulip Ajai Nelson (May 04 2023 at 01:01):

But I do find it interesting. I've always thought it would be cool if Ruby's foo! convention was just syntax sugar.

view this post on Zulip Richard Feldman (May 04 2023 at 01:01):

I don't think it would help in that example

view this post on Zulip Brendan Hansknecht (May 04 2023 at 01:25):

Yeah, i think where this hurts the most in roc currently is things like the random number generator where it is returning a new state and whatever result you requested. And this doesn't help there.

view this post on Zulip Georges Boris (May 04 2023 at 03:15):

is there any benefit of something like this over a pipeline apart from being more familiar to someone used to imperative/mutable programming?

view this post on Zulip Chris Duncan (May 04 2023 at 15:02):

I was thinking the same. Other functional languages solve this by using pipelines.

view this post on Zulip Anton (May 05 2023 at 09:03):

Yeah, it does seem like pipelining would be the best solution for cases like this. The ! syntax seems very unintuitive to me.


Last updated: Jun 16 2026 at 16:19 UTC