Reason: Proposing an alternative to `x := y` and `x^`

[ghost]

The := and ^ are completely foreign to most programmers.
This seems reasonable, since JavaScript doesn't have something like refs,
however this is no excuse to introduce a seemingly arbitrary syntax (especially the postfix ^).

Many people claim, that no syntactic sugar for references seems viable,
but syntactic sugar is not harmful, unless it obfuscates concepts.

And the concept behind refs is getting and setting the contents field (x.contents, x.contents = y).

So a syntax for working with references should not obfuscate that notion,
rather it should be an abbreviation of .contents and otherwise follow the same syntax and semantics.

I propose [] as this syntax and thereby x[] and x[] = y as the new x^ and x.contents = y.

JS people are used to [] denoting obtaining a value out of the object, so this might seem more intuitive.

Also it is very continuous within the language itself: x[i] = y and x[i] are used for getting and setting mutable arrays, lists of values (thus the index), so should x[] = y and x[] mean getting and setting mutable refs, wrappers of a single value (thus no index needed).

Apparently, x[] = y means pushing a value onto x in PHP, which seems not so far away from how it works for references in Reason: you push the new value into it.

It is, for those reasons, a more intuitive, easier to remember, and more familiar syntax for most of us
and should therefore be implemented instead of x := y and the arbitrary x^.

[jonlaing]

I disagree that x := y is foreign. There are a couple other languages that use similar semantics. The first one that comes to mind is Go. I think it would be a mistake to change it, personally.

Re: x^, I can see an argument for that being unfamiliar. It may be controversial, but perhaps another option is using dereferencing syntax from other languages like: *x. I'm sure there are other problems with that I haven't foreseen, but if familiarity is what we're looking for, that's certainly familiar (maybe not to JS devs, but oh well).

[zploskey]

If it can be done without too much trouble, *x for dereference would be most natural for anyone familiar with C. Pascal-style assignment is fine by me and I think fairly understandable.

[wokalski]

Hands up if you use refs in >10% of files at least once. x.contents teaches you about the language instead obscuring the details.

[jonlaing]

In typical functional fashion, I generally try to avoid mutation where I can. I'm fine with being explicit about dereferencing. Then again, given how infrequently I use it, I'm also fine leaving it the way it is. Especially for people who are new to the language, mutable references should be something that is discouraged unless there's no other way to get what you need. In my experiences there's usually more than enough ways to accomplish a goal without them, with rare exceptions. Maybe those exceptions are rare enough that we drop the sugar all together, or we just accept the x^ notation and move on.

[wokalski]

yaaa, me too. This issue is the definition of bike shedding :D.

[strega-nil]

@jonlaing that's not true. x := y is not common in modern languages to mean assignment - it means declaration. Go uses = for assignment, and := for declaration. The same is true of Jai.

I'm very much in favor of x[] syntax, which looks a lot more sane, and is more consistent with the rest of the language (noting x[y]).

:= is only used with ref; = is used with both mutable subobjects as well as array access.

[strega-nil]

@zploskey pascal style assignment would be fine if the rest of the language also used pascal style assignment, but it doesn't: it uses =.

[cullophid]

I use this once for every app I write, so I can't say that I'm too invested in what the syntax looks like. I do think its important that its not familiar to js devs though. Mutation should not feel trivial, or simple. It is a tool that you should only reach for when you have no other options.