newRPL: Simplified matrices proposal

[Claudio L.]

(06-03-2015 01:27 AM)rprosperi Wrote:  Aside from the virtues and possible issues with this approach, which I honestly can't address, I've a short question. One of NewRPL's original goals, I think/thought, was to be compatible with a large percentage of existing RPL code. It seems that a change such as this would break an awful lot of existing code wouldn't it?

I'm not really for or against this proposal, just wondering if my understanding was correct, and if so, how does this change impact that goal?

Good point, let's analyze it.
Programs using vectors [ 1 2 3 ] will remain compatible, since the new compiler accepts the single brackets as equivalent to [[ 1 2 3 ]] (as a matter of fact, it removes the double braces and leaves only single when there's a single row).
Commands that convert vectors into matrices can be implemented as a No-Op to keep compatibility with old sources.
Programs using numeric matrices will remain compatible as well.
The new auto-transpose feature only kicks in for operations that would otherwise issue an "Invalid Dimension" error. So if your existing code didn't have errors, it will behave identically.

The only compatibility problem I see is with programs using lists of lists for symbolic matrices, which now should use square brackets instead. This represents relatively minimum portability effort, and if it bothers a lot of people (I doubt it), it could be handled transparently, for instance using the AXL command when a list is detected as argument. The command AXL could be implemented to always output a matrix, regardless of the input (in other words, leave matrices as is, and convert lists to matrices).

Another consequence (very minor in my opinion), is that when polar coordinates are set, 2 and 3 element vectors are displayed and edited as polar. In classic RPL, you could bypass this using double brackets. In newRPL, I think polar coordinates should be like numbers with a base: retain the coordinate system that the user used to create the vector. Operations should retain the coordinate system of the first argument. So the coordinate system becomes a property of the vector, rather than a system-wide setting.
As far as symbolic polar vectors... to be determined, I didn't think of that yet.


Overall, I think the compatibility impact on existing code is very minimum. Worst case, the user will have to manually change all symbolic matrices to square brackets, but even that could be solved transparently (with a speed penalty, of course).