These are great, valid reasons. I wasn't complaining, was I? How do they not apply to your suggestions? I'm still not sure what you would have us do. Say, "yes you're right"? Go off and rebuild arc like you suggest? Why would that then not suffer the problem of 'learning how it differs from old arc'?
Think of a situation where Arc currently throws an error, like when you try to use `apply` on a macro. Current code cannot use apply on a macro, because of the error.
Now let's suppose we fix that, so apply works on macros... nobody needs to "learn" anything, other than "hey, apply works on macros now!" because the changes are completely backwards compatible.
Arc doesn't expose the internal details of it's data types, what I'm proposing is a way to expose them. Existing Arc programs can't be relying on the internal details because Arc programs can't access the internal details.
Thus, message passing is backwards compatible. The only time people would need to learn message passing is if they actually plan on creating a new data type.
So how does implementing message passing differ from wart? It doesn't change the way existing Arc programs are run. Can I take any Arc program, plop it in, and have it work the same in wart? Message passing is backwards compatible with existing Arc programs.
In other words... you could take an existing Arc program, plop it into the new version of Arc (that has message passing), and it should work just fine. Only the low-level details have changed, but the high-level ones remain the same.
Yeah, I know, but I was referring more to, "what do I need to learn to get stuff to work in wart". I admit that my terminology was less precise than it probably should have been.
