Hacker News Reader

Comment by pmontra | Hacker News Reader

A random thought about the code samples. What do we gain from having to write

    point<~(y=value)

instead of other languages'

    point.y = value

I believe that syntax should be designed to make things simple for developers, not for the designers of languages or for compilers.

View on HN

I don't know anything about the language but the first form suggests immutability (return a new point with the y property = to value), the second looks like mutating a struct

I don't see anything intrinsically different about the two. If anything the established notation of mathematics for hundreds of years is that '=' implies immutability.

The second example suggests to me that `point` already exists, and we're mutating it by changing the value of its `y` property.

<~ looks like an expression for a bulk update of an immutable record.

"point.y = value" is typically a statement for a single update of a mutable record.

I'm not sure how you'd extend the latter to support the features of the former. The meaning is completely different. Different things should look different.

I expand a little my point. This is from Elixir, functional and immutable, which I've been working with for a couple of years

    iex(1)> point = %{x: 1, y: 2, z: 3}
    %{x: 1, y: 2, z: 3}

Of course this doesn't work

    iex(2)> point.x = 4
    ** (CompileError) iex:2: cannot invoke remote function point.x/0 inside match

This is how we do it, verbosely

    iex(3)> Map.put(point, :x, 4)
    %{x: 4, y: 2, z: 3}

Or with a syntax shortcut

    iex(4)> %{point | x: 4}
    %{x: 4, y: 2, z: 3}

A better syntax shortcut would be the usual

    iex(nope)> point.x = 4
    %{x: 4, y: 2, z: 3}

which everybody would understand no matter the language of origin. I imagine that it would require quite an overhaul of the internals of the compiler, but the compiler should bend to us, not us to the compiler. This is my point about obscure language syntaxes.

The problem with the last code snippet is that it looks like mutating the original value, and that would mislead newcomers to the language.

Yes, that's possible. However this is an example from Ruby, which is very mutable but has some immutable features in its standard library.

    2.3.0 :001 > s = "abc"
    => "abc" 
    2.3.0 :002 > s.gsub("b", "B")
    => "aBc" 
    2.3.0 :003 > s
    => "abc" 
    2.3.0 :004 > s.gsub!("b", "B")
    => "aBc" 
    2.3.0 :005 > s
    => "aBc"

I guess that if an immutable language shows some mutable syntax we can expect it to be a short form. Actually Elixir has at least a mutable short form:

    iex(1)> s = "abc"
    "abc"
    iex(2)> String.replace(s, "b", "B")
    "aBc"
    iex(3)> s
    "abc"

The next line would be an error in Erlang and other languages because we can't mutate an already assigned variable there, but Elixir allows rebinding

    iex(4)> s = String.replace(s, "b", "B")
    "aBc"
    iex(5)> s
    "aBc"

I would not understand that. In every language I've used that supported "point.x = 4", the returned value (if there is one) is 4, not point. Bosque's update is more like CONS (or conj) than . =

Your proposed syntax also doesn't have any obvious way to do a bulk update, and I'm not sure what syntax you're proposing for that.

I maintain that it's more important for things to look like how they act, rather than look familiar -- especially if the familiar appearance does something functionally different -- https://stackoverflow.com/a/522168

I think this is nicely solved in Swift.

How? I don't know any way to do a bulk update of an immutable structure in Swift, apart from constructing an entirely new structure and passing all values (not just changed ones) to its initializer.

You can just declare all members of the structure as vars. The structure will still be immutable.

Or to use Scala's syntax which is more clear to me:

  point.copy(y=value)

I really like F#'s approach to this

    let point2 = { point1 with y = value }

https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...

EDIT This is inherited from OCaml - https://v1.realworldocaml.org/v1/en/html/records.html#functi...

"Choosing the equal sign to denote assignment is one notoriously bad example that goes back to Fortran in 1957 and has been copied blindly by armies of language designers since. This bad idea overthrows a century-old tradition to let = denote a comparison for equality, a predicate that is either true or false. But Fortran made this symbol mean assignment, the enforcing of equality. In this case, the operands are on unequal footing: The left operand, a variable, is to be made equal to the right operand, an expression. Thus, x = y does not mean the same thing as y = x. Algol corrected this mistake with a simple solution: Let assignment be denoted by :=."

--Niklaus Wirth (Good Ideas,Through the Looking Glass)

Equals is a verb AND a adjective though. So I disagree it's notoriously bad to use it as assignment. This is a situation solved entirely with = (make these equals) and == (are these equals?).

>Thus, x = y does not mean the same thing as y = x.

Unless it does, or should.

The specfic argument you're arguing here is on that is just a simple syntax. You don't like = for assignment, but I do. You like = for comparison, but I like ==... To be fair === is dumb.

You're arguing that point<~(y=value) makes sense, and I'm still not seeing it.

But why change the meaning of one of the most common mathematical symbols? Every new generation of programmers must then relearn what "=" means. If you see "=" in a comment you are never really sure what it means, is it assignment or is it the standard mathematical predicate?

Most programming languages change the meaning of one of the most common mathematical symbols. There are at least 3 meanings of "X = Y".

Pascal: Is X equal to Y?

C: Change X, making it equal to Y.

Mathematics: X is equal to Y.

Those are all valuable in programming. Normally programmers get the mathematical meaning via a feature such as __assume or __builtin_expect or assert. It can be used for optimization. When the constraint is violated, various bad things can happen. The code can run slower, halt with an error message, or behave in an undefined way.

Every new generation of programmers starts off expecting the mathematical meaning. I don't know of any programming language which uses it. Ideally that would be fixed, but the change might be difficult for the current generation of programmers.

Note that the Pascal meaning can be fairly compatible with the other meanings. The solution is simply to be aware of context. On a line by itself, X=Y makes no sense as an equality test. Within the controlling part of an "if" or loop, assignment need not be supported. That does the job. Alternately, the meaning could change by having a keyword in front for assignment ("let" is popular) and/or for the assertion. So we could distinguish all three meanings with syntax like "if X=Y", "let X=Y", and "assume X=Y".

It's not changing the meaning at all. You're picking your preferred meaning, and I'm picking mine. Mine happens to be the almost universal standard for programming.

Most lines of code are written as true statements. If you understand how a computer actually works at the register level you'd see that

x=5; has a result. And it's not 5. It's TRUE. I'm not asking if x equals 5, I'm saying HEY YOU, X IS EQUAL TO 5. I'm telling the computer this is now the truth. 5 is moved into the x RAM location and the result is true, because the CPU is doing what I told it.

You're just wrapped up in your semantic view. There is nothing wrong with = for assignment and == for evaluation. Someone would complain if it was the other way around, so just accept this is the standard - or make your own language that "does things right". But.... Just because it isn't the way you like it, doesn't make it wrong.

Lisp, the second oldest language after Fortran, didn't make this mistake. In Lisp, "=" isn't an operator at all. Assignment is (setf x y) and comparison is (eq x y) [and several variants of eq].

Common Lisp and related languages have = as a function: it is a numeric comparison. Like under equalp, (= 1 1.0) yields true. You might think it's superfluous to equalp, but has some virtues of its own, like supporting variadic arguments (= 1 1 1 1) and rejecting non-numeric arguments.

eq is often the wrong one to use: two instances of the same number can fail to be eq.

This is a bulk record update, according to what I can find in the docs. It's an atomic operation -- meaning, if instead of updating one field, you updated thirty fields, all would appear to take place as one operation.

Obviously someone please correct me if I'm wrong.

Reply on news.ycombinator.com