Prism Rationale, Part 2

[RE01 Rice Brian T. EM2]

> I call this the problem of the right abstraction. I indexation is
> explicitly used when it is not needed, you are using the wrong
> abstraction. And you will not be able to operate on a non-indexed
> collection without rewriting the code. So at every moment, you should
> the right abstraction, which has the right amount of semantics. If you
> have too few semantics, your function will be too complicated and will
> contain code that would likely be reused somewhere else. But if you
> have too many semantics, you add unnecessary constraints. 
> 
you seems to have some special method for "counting" semantics.  how do you
invoke this?  your viwepoint suggests that you look at abstraction as a
system of levels, ordered as though on a number line.  in my experience,
i've found that the concept of "abstraction" is so relative that one can
call implementation the abstraction and abstraction the implementation of
the theory encoded by such a program into _one_ domain of concepts.
furthermore, who says that the domain that you think a problem works in is
the only domain worth considering?  what makes your ontology _the_ ontology
to work with?  i don't think that you have the intellectual right to assume
such a stance, as you seem to do.
all of this is the reason for my having developed the Arrow system.  so far,
i have been on the defensive with my explanations, so to speak, since i have
been explaining only how the system does only as much as current systems.
the _real_ benefits have yet to be analyzed, and i think that those results
will surprise you a great deal.