Bug or Feature? val.x:=3

[IHarwell]

I ran into a curious behavior that I don't fully understand. Anyone know if this is a bug or feature?

In CAS mode, enter "val.x:=3". This constructs a special type of list (I'm not sure what the precise difference is, but it IS different somehow.)

At this point, val is a list according to TYPE(), but is shown like a matrix. The value of val is [[x 3]].

This looks like some form of associative list to my eyes, but this is where the weirdness starts.

Entering "val.x:=5" results in a curious situation. The value of val is now [[x 5][x 5]].

It appears that the instruction has both modified the existing entry and added a new identical row. I can't seem to figure out why this is. My current best guess is that the "val.x" syntax basically uses "val" as a separate namespace from the global CAS space, and the value of "val" looks like the sequence of instructions within that namespace.

Does anyone know more about this? What is the "val.x" syntax (AKA "val::x") in CAS mode?

What is this supposed to be used for, for example?

Short Addendum: I ran across this while looking for a way to better manage variables for complex systems. For example, using Beam1.tau to represent torque on Beam1, Beam1.F to represent the set of forces on Beam1, etc. The same could then be repeated for Beams 2 through N, and the resulting calculations would be, in theory, easier to follow. The main problems with this are that the CAS system doesn't show what you type before the ".", a mistake in entering values in the "modify AND add" system means you have to rebuild the whole Beam if you make a mistake in one variable, and I'm still unsure how the syntax above works with the rest of the CAS system.

As an aside, if I could get it to work, it would allow at least partial OOP in CAS programs. That would be really nice, as the Python implementation is still buggy and has significant startup lag and has quite a few bugs in it that make it impractical for larger programs.