1. New assignment operator "=&"
- Posted by petelomax May 19, 2017
- 1248 views
Stop me if you've heard this one before.
This thought occurred to me when trying to translate some Ruby unshift statements.
We've got append() and prepend().
We've also got a &= b which is equivalent to a = a&b.
I propose a new operator a =& b which is equivalent to a = b&a.
Thoughts? Are there any cases this would foul up existing code?
Would there be a similar need for =- and =/ (assuming += and *= suffice)?
Pete
2. Re: New assignment operator "=&"
- Posted by _tom (admin) May 19, 2017
- 1212 views
A start of a new rant...
Start from first principles.
Euphoria|Phix is Friendly, Flexible, Fast.
- only found here
- quantifiable
I can objectively prove this claim counting features and measuring performance. Yes, you can say your favorite language is wonderful, but not Friendly|Flexible|Fast.
What makes Friendly?
- patterns
- predictive
- perpetual
Inertia thinking results in messy code.
x = x + 1
Very common in code. It is natural to wish for a shortcut. ( For some reason it is more natural to write x = x + 1 instead of x = 1 + x )
x += 1
We end up with this syntax because it "looks convenient" at the time the syntax was created; maybe it was easier for the parser to emit an error if
=+
was found.
Using this existing pattern we try:
x &= 1
Let & stand for "append" so
x = append(x, 1 )
is a logical syntax extension.
But, there is no symbol for "prepend". And why should we think of & standing for just "append"?
Show me the syntax
Testing the current ⵚE behavior:
object x x = {1} x = prepend(x, 3 ) ? x --> { 3, 1 } /* x = {1} x =& 3 ? x -- crashes -- Syntax error - expected to see an expression, not '&' -- x =& 3 -- ^ */ x = {1} x = append(x, 3 ) ? x --> { 1, 3 } x = {1} x &= 3 ? x --> { 1, 3 }
We could argue that there is a pattern break|incomplete here.
Ideal Pattern
This makes sense if we were to design a clean syntax.
Given a pattern like
Fore | Aft |
---|---|
x = prepend(x, 3) | x = append(x, 3 ) |
x &= 3 | x =& 3 |
--> { 3, x } | --> { x, 3 } |
This means you can predict
Fore | Aft |
---|---|
x /= 3 | x =/ 3 |
x = 3 / x | x = x / 3 |
This also means it is perpetual
Fore | Aft |
---|---|
x += 3 | x =+ 3 |
x = 3 + x | x = x + 3 |
Non breaking pattern
This makes sense if you don't want to break existing code.
Given a pattern like
Fore | Aft |
---|---|
x = prepend(x, 3) | x = append(x, 3 ) |
x =& 3 | x &= 3 |
--> { 3, x } | --> { x, 3 } |
(This does look "backwards" to me.)
This means you can predict
Fore | Aft |
---|---|
x =/ 3 | x /= 3 |
x = 3 / x | x = x / 3 |
This also means it is perpetual
Fore | Aft |
---|---|
x =+ 3 | x += 3 |
x = 3 + x | x = x + 3 |
So lets say that & means "glue" (not append).
Pattern for +
Addition and multiplication are commutative: 3+x is the same as x+3 .
The "commutative pattern" means that x *= 3 and x =* 3 should produce the same answer; both ways of writing should be available.
Assuming the parsing machinery works the same for all operators this does not harm--having a pattern not work is more irritating.
We already have 5 and +5 with the same meaning; it does no harm but follows the logical pattern for use of the "plus" and "negative" signs.
Existing
atom x = {1} x &= 3 ? x --> { 1, 3 }
Since the & symbol comes before the = symbol it makes sense to say this means "prepend" but what we get is "append".
What we now have is a "convenient syntax" that does not extend well. This kind of thinking shows up in conventional languages that end up having lots of rules and exceptions to those rules--all in the interest of adding a convenient feature.
Break Stuff or Not
Make Phix "more Euphoric than ⵚE"; the big picture.
If you wish to fill out the syntax and make it pattern|predictive|perpetual there has to be a break with the old way of thinking.
Of course, breaking code fails the "prime directive" of not harming your users!
You can create an extension (only slightly ugly) that fills in the need for a more Euphoric Phix.
_tom