Intersperse can be more succinctly written as:

intersperse:{raze ((-1 _ y),\:x),-1#y}

This works only of you intersperse an atom into a list. If you intersperse a list into a list of lists it doesn’t do the right thing:

q)intersperse [(0;0);((1;1);(2;2);(3;3))]
1 1 0 0 2 2 0 0 3 3

Also zip:(,’) zips correctly only lists of atoms.

q)zip:(,')
q)first first zip [((1;1);(2;2);(3;3)); ((4;4);(5;5);(6;6))]
1
q)zip: { x {(x;y)}' y }
q)first first zip [((1;1);(2;2);(3;3)); ((4;4);(5;5);(6;6))]
1 1

I’m more of a Haskell enthusiast than serious practitioner, but I have been programming in Q for a while. Thought I’d comment a little on the translations you’ve provided.

There are built in functions for head and tail (first and last).

Intersperse can be more succinctly written as:

intersperse:{raze ((-1 _ y),\:x),-1#y}

This uses the each-left, which works like the apostrophe each adverb, but only across the left join element.

If you’d like to turn a function composition into a function itself, you need only surround it with parentheses. So, for example, zip becomes:

zip:(,’)

Also, there is a built in map function: each

q)enlist each 1 2 3
1
2
3
q)enlist each 1
,1

If you haven’t already, you should email Simon or Charlie about getting access to the K4 list box.

In my view, the best candidates for “very high level” languages with a mathematical foundation are dependently typed languages–such as Coq, Agda and Epigram. These are conceptually very similar to Haskell, and Coq programs can be trivially translated to Haskell or ML code.

I’m writing a new SETL compiler now. When done, it will have even more expressive power than Haskell.

It will also, I promise, be *much* faster.

You can learn more about this work at my blog:

http://daveshields.wordpress.com

See especially the post on Moore’s Law and Software. All the rest is detail.

thanks,dave

But this is run of the mill stuff in ZFC. Consider how one would define a relation on a set. Theoretically we can describe relations in ZFC terminology, and we can certainly discuss the properties of one if we have it, but in order to actually have a real live relation on a real live set we need to appeal to some oracle which knows what thingees actually are (unless we’re dealing with simple relations that never inspect their arguments). Only these implementation oracles need to know about “types”, but even then we can usually get away without it. In my example we don’t actually have to know what a type is, we only need to know enough to be able to discuss that a thingee happens to be a function (from some carrier back to the same). Set theory has functions, it just describes them as being from one set into another. Functions can be elements in a set or a model just like anything else, nothing to see here.

Indeed, category theory is foundational just as much as ZFC is. It’s just that when CT discusses “sets with additional structure” it’s interested in that structure rather than in what’s beneath it. Given the focus on structure-preserving transformations, what’s actually beneath frequently doesn’t matter anyhow. For someone steeped in set theory it feels like everything is turned on its ear because set theory is so very concrete and so very interested in the little elements rather than in the big structure. But it’s in focusing on the big structure irrespective of the particular elements where all the revelations of CT come from.

As far as proof libraries go, I’m not familiar enough with the libraries for theorem provers to offer any suggestions. However, there are things like the category-extras package in Haskell which implements a great deal of theory, including features like passing around proofs of properties on a type. Perhaps that’s too far across the Curry–Howard isomorphism for what you’re interested in, but it’s out there. (Much of the attendant documentation was on the developer’s blog which crashed a while back.) There’s also various work on generating free theorems, which is more type theory than category theory proper, though there’re deep connections between them.