Lambda the Ultimate

I read that one of the big things about F.P is the ability to reason about programs/prove them; is there also much more scope for code-generation.. automatically filling in the gaps after manually transforming one part of a system

lets say you have a known datastructure X and some known function F
and you want to transform the datastructure via G, and you want another H function to produce the same result..
F(X) = H(G(X))

my question is, in the functional programming world is there the ability to auto-generate 'H' given 'F' & 'G' (i guess even the ability to verify manually written functions fit the bill would be usefull)

has this sort of thing been used in practice to solve any real word problems, at what level of complexity..

Any pointers for things to read up on along these lines.

I have been reading about limits and colimits in Category Theory. Is it the case they are both universal arrows from a functor to the coresponding diagonal functor?
TIA.
Chad.

In the recent set of discussion on functions vs procedures a reference was made to the ADA language design choice neither to ban side effects in functions nor specify the order of evaluation of expressions.

So let me explain why this upsets me.

Thus thanks to our indecision coupled with human incompetence of the average programmer.. if you run a large program on a different compiler, or a different version of the same compiler, or with different optimization settings.... expect different results.

If you look at large modern commercial software systems... a large chunk of the cost (even worse schedule time) is in testing and retesting.

Mostly our test department goes hunting in areas where we have introduced change.

However, bad language design choices as made by the Ada design team add to the need for us to say to the test department... "Ah, we've had to change X (where X is one of that list above), so anything is possible. Sorry, you have to retest everything."

This can easily result in the vast proportion of the cost of a release being in the test phase. Which can be devastating to the release date schedule, as they are _always_ on the critical path. (Final test comes after everything else is done and dusted)

Determinism SHOULD feature highly as a design criteria for language designers.

Yes, programmers shouldn't code bugs.... but get real. In very large industrial systems there are hundreds even tens of thousands of bugs in shipped systems. Thus it is important that wherever possible, even if the program is just plain rong, different compilers, compiler versions, optimizer settings and memory layout, wherever possible produce the _same_ tested and accepted wrong behaviour.

Obviously it will not always be possible.

Obviously wherever possible defects should be prevented from being written, defects should be detected and fixed.

But simple language design choices that "prematurely optimize" by destroying determinism cost millions.

Determinism matters.