[Axiom-developer] [Tuples Products And Records] functional-categorical programming versus object-oriented programming

[billpage]

Changes 
http://page.axiom-developer.org/zope/mathaction/TuplesProductsAndRecords/diff
--
William Sit wrote:

> Sorry these discussions get longer and longer.

On the contrary, that *is* one of the purposes of this web site.
I will expand on that point in the [Axiom Colloquium].

> Let's hope we can come to some understanding.

Yes, I think so. Afterall, mathematics is an *objective* science.
But sometimes this does required considerable effort and patience. :)

> Mapping(C,A x B) has no meaning in Axiom.

But I have already written the equivalent:
\begin{axiom}
f:Mapping(STRING, Product(INT,FLOAT))
\end{axiom}
and this has a clear meaning in Axiom. Using names like
\begin{axiom}
C:=STRING
D:=Product(INT,FLOAT)
f:D->C
\end{axiom}
makes no difference. My view is that
\begin{axiom}
f:Mapping(STRING,INT,FLOAT)
\end{axiom}
should have the same meaning as the previous expression.
The fact that is doesn't seems unnecessary and confusing.

About Cartesian closed categories:

> Always nice to learn new jargon.

But the concept of a [Cartesian Closed Category] is much
more important than mere jargon! It provides the categorical
basis for typed lambda calculus and thus essentially all of
the theory of computation, modern functional programming and
languages such as OCAML.

> Encapsulation is where one starts going into the realm of computer
> science. This is where the "subtle distinction" originates.

In the context of Axiom I strongly object to creating such
"subtle distinctions". Axiom is intended to be a system for
doing mathematics with a computer. I think the programming
language in which we express mathematical algorithms should
be a close as possible to the actual mathematics. This is one
of the things that distinquishes Axiom from other "engineering-
oriented" computer algebra systems like Maple and Mathematica.

> In mathematics, there is but one Cartesian product of A and B.
> In computing, there are two, a raw version (A,B) and an
> encapsulated version Product(A,B).

To me, when applied to Axiom this is wrong! wrong! wrong! :)
We do not need this kind of distinction.

> If I write a mapping in Axiom, 'f:Complex Integer->Float', would
> you say f has arity two just because a Gaussian integer may be
> represented by two integers?

No. I think the product '(A,B)' in the signature of a function
(mapping) such as 'f:(A,B)->C' plays a more fundamental role in
the semantics of the Axiom programming language than derived
domains such 'Complex Integer'. That is why the domain 'Record'
is considered a "primative". These are the basic types of things
that we need to define more complex things.

> It is the idealistic mathematical view which identifies the two
> that creates "vacuous" wraps and unwraps "where none is necessary".

No. There are no unnecessary "wraps and unwraps". This is just
normal paramater passing. The compiler only needs to do what
is usually necessary to pass, for example the tuple (a,b) i.e.
object of type Product(A,B), to the body of the function by
pushing the values of the projections onto the stack.

> It makes no sense to encapsulate objects from unrelated domains
> just because they happen to be the argument types of some function.

I disagree. This makes perfectly good sense in the context of the
cartesian closed category CAT of small categories. I think this
the foundation on which all of Axiom's algebra and it's programming
language should be based.

> why should the data-structures be the "canonical" cartesian product
> structure

Precisely because of the special role that products play in the
concept of a cartesian closed category.

--
forwarded from http://page.axiom-developer.org/zope/mathaction/address@hidden