On 15/05/2011, at 8:34 PM, john skaller wrote:
Oopps ..
> Basically if you have type category T, and lets consider a 2 argument
> function, then
> with a tuple the kind is
>
> T -> T
This is wrong, the kind is just
T
>
> but with Rust two argument function the kind is
>
> T * T -> T
Sorry!
So more correctly the kind of the domain, codomain, and function with tuples is
T,T,T respectively
and with multiple arguments is
T * T, T, T respectively
The handling of n-ary combinators like tuple formation appears to require
high level polyadic programming (functorial polymorphism).
By comparison, currified functions like:
U -> U -> U -> U -> ...
can be decomposed into a list which can be handled relatively easily
by higher order polymorphism and recursion. This doesn't work for
tuples because tuple formation isn't associative. I believe this could be why
Haskell
uses currified functions as standard instead of tuples ( the -> combinator is
right associative so can be handled by a single binary function and recursion,
in particular just a fold).
[BTW: the usual "hack" to solve this is to break the tuple term into a list,
process it with recursion, then rebuild the tuple, but this does NOT work
properly. Basically this needs a "flatten" operator but flatten is ill defined
because you can't tell how "deep" to flatten.]
The impact on a programming language is that it is hard to compactly
generalise tuple handling. To handle tuples up to N components you need
N combinators, or, N^m, if you're combining them.
I have actually worked on a language which could do this, designed by
a top flight category theorist. So actually it CAN be done and it isn't hard
but I for one don't understand enough of the theory to design a language
in which it can be implemented.
--
john skaller
[email protected]
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
