Maps in l-values are ready

[Jose E. Marchesi]

Good news everybody!

The support for having maps in the l-value of assignments landed to
master!

As you know, Poke values can be mapped or not mapped.  Simple values
(integers, offsets, strings) cannot be mapped values.  Arrays and
structs can.

This means that the following map operator generates a not-mapped
integer value:

(poke) defvar n = int @ 3#B
(poke) n
16843284
(poke) n'mapped
0

Therefore if we assign another value to the variable n, the integer in
IO space at offset 3#B does _not_ change:

(poke) n = 666
(poke) n
666
(poke) int @ 3#B
16843284

In contrast, arrays and structs can be mapped values, and therefore
accessing the elements of a mapped array or the fields of a mapped
struct _do_ change the IO space:

(poke) defvar p = Packet @ 0#B
(poke) p.foo = 10
(poke) Packet @ 0#B
Packet { foo = 10 }

Due to the inability of simple values to be mapped, up to today we were
forced to use a rather ugly idiom to map simple types in the IO space:

(poke) (int[1] @ 0#B)[0] = 66

.i.e to map an array of one integer at the desired offset and then write
to it's only element.

No more of that nonsense! :D

Starting today, it is very easy to poke simple values to the IO space.
Just write a map in the left hand side of an assignment!

(poke) int @ 3#B = 25
(poke) string @ 10#B = "foo"
(poke) offset<int,B> @ 0#B = 13#Packet

Happy poking!