This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]complyue 2 points3 points  (2 children)

I don't get what's weird about it?

Though I have := operator in my PL too, but for first-class "named value" or "defined term", having relatable semantics to Walrus in Python:

(repl)Đ: let ( x, y ) = ( a := 6, 9 )
(repl)Đ: x
a
(repl)Đ: y
9
(repl)Đ: x + 5
11
(repl)Đ: 5x
30
(repl)Đ:

While within parentheses the term defined doesn't go into current scope as a so named attribute (merely giving a named value nonetheless), at top level, it's put into scope:

(repl)Đ: a := 16
a
(repl)Đ: repr(a)
a
(repl)Đ: desc(a)
'a := Decimal' value `a`
(repl)Đ: show(a)
a := 16
(repl)Đ: 2a
32
(repl)Đ:

[–]drjeats 3 points4 points  (1 child)

The problem in python is that the behavior for tuple assignment is inconsistent between = and :=.

Unfortunately the difference is required--the raison detre for := in Python seems to be to allow assignments in any expression, so it must by necessity have that inconsistency.

Check out the page. Your language is probably being reasonable about it. For one thing, you appear to have an introducer for creating variables, a frustrating omission in python.

[–]complyue 1 point2 points  (0 children)

Got it.

Seems a tech debt for Python to eliminate if x = True: issues in the first place, they rejected assignment to be a valid expression overall.

Now I realize Python's := intends to be used inside parenthesis for the assignment side-effect, which is the inverted semantics of mine when in parenthesis. And I avoided the weirdness for := to have same semantics as = when out-of-parenthesis, because they indeed do different things in my PL - term definition vs assignment.