### 1. New assignment operator "=&"

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 "=&"

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.

• 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