[Axiom-developer] [Tuples Products And Records] [Tuples Products And Records] Arity and names

[William Sit]

Changes 
http://page.axiom-developer.org/zope/mathaction/TuplesProductsAndRecords/diff
--
Bill Page wrote:
> William Sit wrote:
> 
> > 'Product(A,B)' is not the same as '(A,B)' computationally, as it is
> > currently in Axiom.
> 
> Yes, I agree that is true in Axiom as it is now. But I am thinking about
> how Axiom should be not how it is. 

If we are really only talking about what Axiom *should* have used as *notation*
for multiple inputs, then I think 'A x B' would be the best. It would be trivial
to implement this syntactic sugar.

> The mathematical concept of product
> is straight-forward and there is no reason why '(A,B)' where 'A' and
> 'B' are domains should not denote this product.

Exactly, so why are you still insisting on calling it 'Product(A,B)'?

> The derived domain Product, as it is defined now in Axiom is rather
> more complicated than what one needs for defining a Mapping for
> a function with more than one input. The domain Tuple on the other
> hand is too restricted. Axiom's built-in primitive domain Record
> is just about right.

What difference does it make to use '(A,B)' vs 'Record' other than wrapping?
'Product(A,B)' is more complicated precisely because it is to be used for other
(higher level) applications, where as '(A,B)' need be only the vanilla Cartesian
product.
 

> > You did not answer my question on arity.
> 
> Do you mean the question of the arity of, for example the following
> function::
> 
>   f:Product(A,Product(B,C))->D
> 
> My answer (assuming that you accept the notion of Product as a
> primitive domain) would be that this function has "arity" of 3
> since in a Cartesian closed category (CCC) we have
> 
>   Product(A,Product(B,C)) = Product(Product(A,B),C) = Product(A,B,C)
> 
> Axiom actually takes the domain Record as primitive rather than
> Product. The equivalence of constructs such as::
> 
>   Record(a:A,b:Record(a:B,b:C)) = Record(a:Record(a:A,b:B),b:C) =
>   Record(a:A,b:B,c:C)
> 
> is a little less obvious but natural coercions (isomorphisms) could
> be provided which make the question of arity clear in this case as
> well.

Would you say that 

f:DirectProduct(5, INT)->INT

has arity 5 then? And to do so recursively? Give me a break. What is wrong with 

f:(A,B,C)->D

having arity 3 *without* recursing into 'A', 'B', 'C'? I have no objection with
that. I don't see your reason for insisting on writing '(A,B,C)' as
'Product(A,B,C)' and STILL interpreting it the same way as '(A,B,C)'. I guess
you just don't like the notation '(A,B,C)' for Cartesian product. You have every
right to prefer your notation, but I like to hear other people's opinion.
 
> > The design of the domain Product(A,B) need not be dominated by the
> > two projection maps.
> 
> That is not true. The very nature of what we mean by product is
> defined in terms of these projection maps. The product is what is
> known as a type of limit in category theory. It is defined by a
> universal property which makes the product and it's projection
> maps unique amoung all other such objects and maps. See for
> example:
> 
> http://en.wikipedia.org/wiki/Limit_(category_theory)

Bill, I fully know how a product is defined categorically (I took such a course
with Eilenberg and kept a copy of Mitchell's text at arm's length). What I am
saying is, for the purpose of computing, it is reasonable, and perhaps even
desirable under suitable environments, NOT to implement an *external* interfaces
for the projection maps in a Cartesian product -- which is why it is
encapsulated (to faciliate the information hiding, for example 'A' may be your
Social Security Number and 'B' your bank account password) into something else
we called 'Product(A,B)'. The projections maps can be available internal to the
package. (Of course, currently, 'Product(A,B)' does export projection maps, but
my point is: once packaged, 'Product(A,B)' is not the same as '(A,B)'
computationally because it may serve other purposes, and whether it remains
vanilla Cartesian product or or not is not the issue). If you do not like the
name 'Product' to be used or associated with this new package, fine. But we are
not arguing about just naming conventions, I hope (that would be endless
discussion because there are many names we don't like). 

> > Consider the two ways of coding ... f, g
> 
> Using the Record constructor in Axiom this function can be
> written as:
> \begin{axiom}
> h:Record(a:INT,b:INT)->INT
> h(parameter) == parameter.a + parameter.b
> h[1,2]
> \end{axiom}
> 
> which is almost as convenient as your definition of 'g'. Syntactically,
> the name 'parameter' could be eliminated for brevity. There is no
> reason that the compiler should produce less efficient code for this
> notation.

But the arity of h is one, not two, despite your use of h[1,2], which is really
parsed as h([1,2]) in Axiom.

William

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