Re: Liskov Substitution Principle and Abstract Factories

From: Mark Nicholls (nicholls.mark_at_mtvne.com)
Date: 01/21/05 

Date: Fri, 21 Jan 2005 13:19:13 -0000

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:npnwhf6bpwlf$.nr8djb5pimp4.dlg@40tude.net...
> On Wed, 19 Jan 2005 13:22:38 -0000, Mark Nicholls wrote:
>
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> > news:3zevehgd1j6f$.8hpzxjpt8et2$.dlg@40tude.net...
> >> On Tue, 18 Jan 2005 10:56:41 -0000, Mark Nicholls wrote:
> >>
> >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> >>> news:qukbppdmnots.lw5s8wh9kdms$.dlg@40tude.net...
> >>>> On Mon, 17 Jan 2005 14:21:24 -0000, Mark Nicholls wrote:
> >>
> >> Call it intuition, but it is
> >> not a probability. Let you be 99% sure that God exists? What could
follow
> >> from that?
> >
> > I would probably start going to church.......at least 99 Sundays out of
100.
>
> Like a man who regularly visited church, synagogue and mosque just in
case,
> somebody of them is right. Unfortunately gods of all religions are
jealous,
> they don't tolerate unfaithfulness... (:-))

you do not subscribe to Pascal wager then?

>
> >>>>>>>>> Is the weather deterministic?
> >>>>>>> or just so complex as to not submit to complete analysis.
> >>>>>>
> >>>>>> It is not because of complexity. The analysis we could do is based
on the
> >>>>>> laws (thermodynamics) which are of statistical nature.
> >>>>>
> >>>>> Thermodynamics (as far as I remember) is not statiscal.
> >>>>
> >>>> It is. Temperature, pressure, density, all are statistically defined
> >>>> values.
> >>>
> >>> I seem to remember lots of differential equations.......
> >>>
> >>> I would assume that temperature is some sort of absolutely defined sum
of
> >>> kinetic energy of particles.....but because we cannot practically
observe
> >>> that we make assumptions.
> >>
> >> I remotely remember that all laws of thermodynamics are statistical.
> >> Nothing prevents the gas molecules to separate themselves so that cold
and
> >> hot ones will gather on different ends of a tube. Yet, an engine built
on
> >> this principle is impossible, statistically impossible. Mechanically it
is
> >> perfect: catch a Maxwell daemon and here you are.
> >
> > Are you saying that the laws of thermodynamics and mechanics are
> > contradictory?
>
> Honestly, I do not know, if one could derive thermodynamics from Newton
> laws assuming that molecules were ideal billiard-balls. It is far beyond
my
> knowledge. I only suppose that it might be very non-trivial or even
> impossible. Compare with deriving arithmetic from the set theory.
>
> >> Different laws. You are outside of thermodynamics then.
> >
> > If they are consistent (I would hope), then I should be able to create a
> > mechanical model that absolutely predicts the weather (given absolute
> > data...which is dubious).
>
> I do not think you will be able to do so. You have to track down
> interaction of particles, these are controlled by chemistry, physical
> chemistry and in the end by quantum mechanics, which is inherently
> stochastic. So the macro system will be random as well. Therefore the
> weather is truly random, it is not a fake randomness of *random* guessing
> about weather.

OK, it is chaotic....and the nature of quantum mechanics would render it,
non determinitistic....though predictable in some sense.

>
> >> We cannot apply statistics just because something is impractical to do
> >> right.
> >
> > really?
> > why not?
>
> Because it might turn impractical as well.

you may as well have a go though.

> Would you use statistics to
> manage your bank account?

it's called management accounting...I think...

> If you do not know the right way to do something,
> you do not know it.

yes,

but not knowing exactly what to do, does not mean the optimal strategy is to
do nothing.

> Statistics is just a way to do something you know to be
> done with statistics. (:-))

!

>
> > Is this not the case with thermodynamics?
>
> No, because the laws of thermodynamics were proven (not falsified) by
> physicists.

statistically proven....please....they are almost certainly not completely
correct....until (if) we have the grand unified theory, they can only be an
approximations (probably!).

> They have a definite area of applicability etc. Possibly
> similar thing could be done for software development, but as I said before
> I do not believe it that.

you believe before you have even tested it.

If I tell you god is sitting behind a door, you will say...."I don't believe
in god, so I wont look"......this is the religion of the skeptic.

>
> >> No. Prime numbers are good for pseudo-random generators, but they are
not
> >> random. "Pseudo" vs. "truly" is crucial difference. A truly random
sequence
> >> cannot be evaluated by no way. Prime numbers can be. The complexity of
the
> >> method is irrelevant here. That's the axiomatic of mathematical
statistics.
> >> The theory of hidden parameter, you are referring, if true, would make
> >> statistics inapplicable, altogether.
> >
> > but nothing is truly random (or at least very little, unless we start
> > talking about quantum mechanics, and then I would suggest that if you
cannot
> > see in the box, is the cat alive or dead?, if you cannot see inside the
> > program, does it work or not?).
>
> It is a philosophical position, you know. In my view things are truly
> random. I'm with Bohr, against Einstein here. I do not trust in the theory
> of hidden parameter.

That's beyond me.....

Does this all come down to.....

you seem to 'believe' that the probabiliy of an outcome of an event, is not
the same as the probabiliy of the observation of an event, once it has taken
place....i.e. something like

P(you toss head) != P(you tossed heads, but I haven't looked yet)

I 'believe' they are the same....the probabilities are relative to the
observer to me.

>
> >>> Rather like a program.
> >>>
> >>> I did say there were lots of problems....the chaotic nature make small
> >>> errors magnify, I accept, but even so I 'know' its not going to be 29
> >>> degrees C tomorrow in London.
> >>
> >> Ah, but statistically it is well possible! The probability is not 0.
> >
> > no, but it is something like 0.00001%
> >
> > thats useful
> >
> > If the probability that program P does XYZ, 99.9999%, thats pretty
> > useful....good enough in fact, for almost any purpose.
>
> Ah, here we go again! (:-)) In my view there is no probability that P does
> XYZ. There is only a probability that your random guess about P is true or
> false. It does not depend on P, it depends solely on your ability to
guess.

OK....maybe I'll buy that

P(my belief that P with do XYZ, and it does) = 0.999999

(to me they are the same...but we can leave that)

>
> > If warming up is better than being cold, then do it.
> > If it is impossible to overtake, but it's useful to be a little closer,
then
> > start running.
>
> Yep, NASA should train astronauts to climb trees. After all that would
> bring them closer to the Moon. (:-))

yep....

or put telescopes on the top of mountains to make them 1/2 mile closer to
stars that are thousands of light years away.

>
> > I create a model......
> > I make statistical predictions.....
> > someone questions the model.....(using a statistical model)
> > and then makes statisical statements about the model.
> >
> > so....
>
> ...nobody could tell you what does it mean.

you want meaning?

you may be asking too much.

>
> >>>>>> But a program is perfectly predictable.
> >>>>>
> >>>>> Once it is completely observed, before the observation it isn't.
> >>>>
> >>>> No, it is a property of a program to be predictable. You know that
y=f(x),
> >>>> i.e. that for any given x there is one y. If f were random you could
not
> >>>> say so. You would have Pr(y|x) instead.
> >>>
> >>> you can!
> >>>
> >>> For it to be random, does not mean it is utterly unpredictable.
> >>>
> >>> Toss a coin.....it comes out head or tail....it is random, yet there
is only
> >>> 1 answer and that answer is specifically defined to be a member of a
set of
> >>> 2.
> >>
> >> So you have Pr (Head | try no.=n). You do not have Head (n)
> >
> > I do not understand Head (n)..
>
> The function that for given n returns Head = true or false.

yes....so....

no....but it may give

P(head) =
0.99999999999999999999999999999999999999999999999999999999999999999999

and that may be good enough.

>
> > If I do not know how head/tail is distributed...I run an experiment to
> > statistically guess the value.
> >
> > If it comes up 1,000,000 times head and 1 tail....I think I could
probably
> > reasonably safely say it is not a 'fair' coin.
> >
> > If you ask me what it will be when you toss it again, I will say
> >
> > "heads"
> >
> > I do not 'know', but heads will probably be good enough for my
> > purposes.....and probably be correct.
>
> 1. How do you define the purposes?

that depends on the context....if it's UAT...then the purpose is the costs
associated with the 'errors' against the benefits of it's use.

> 2. Why do you know that it is good enough?

because I have a formula that tells me,

bool MarginalValue(marginalcost, marginalbenefit)
{
  return (marginalcost-marginalcost);
}

when that's > 0, you make the decision.

> 3. How do you know that the coin does not have a counter set to 1,000,000.
> BTW, navy widely uses pass-counters for their mines. Would you experiment
> with such mines?

I don't.

but I make a (statistical assumption that such problems wont).

how do you know of the existence of the empty set?

my formula MarginalValue, would tell me to be careful with mines.

> 4. And finally, how "probably correct" is any better than "probably
> 'head'"?

because I can use it to give me good long term estimates based on single
experimental probabilities

I can get to

E(total value) = E(sum (marginal value * probability))

>
> See above. As Littlewood noted probability introduces vicious circle. Once
> you get in, there is no way out.

quite.....so there goes physics......

all we are left with is hard logic.....

and that's based on a 'belief' in a set of axioms......

oh dear.

>
> >> Many, many are quite sceptical about Bayesian approach. But that's
another
> >> story.
> >
> > The whole of statistics is dubious in some sense, yet its good enough
for us
> > a lot of the time.
>
> To be consistent, you should say: there is a probability that it is good
> for us. (:-))

quite :-)

though that obviously upsets me.

>
> > maybe the question about program correctness is more like
> >
> > Pr (amount of bucks > Y)
> >
> > than
> >
> > Pr (X = right number)
>
> Alas. But that's rather a sociological problem.

so?

>
> > maybe the question is
> >
> > Pr(Program is fit for purpose)
> >
> > rather than
> >
> > Pr(that pressing button OK, will do ABC)
>
> The problem is how to define the purpose. A usual way is: purpose =
> fulfills the requirements, and requirements are sort of "pressing OK does
> ABC". How would you do it otherwise?

There are many problems with that approach, as you know.

That way needs to be exhausted to the point where

E(benefit) > E(cost)

If there are less rigourous ways that are cheaper to fulfill, though
potentially less powerful....then they have a place.....if they take us into
areas where hard logic fails....then thats even better.

>
> >> So you have to
> >> sample a large statistics to test some hypothesis. But with in the case
of
> >> a program the size of the statistics needed (provided some very strong
> >> assumptions I don't believe be true) is so giant, that you will be
unable
> >> to estimate anything. See also below.
> >
> > I think we do it now.
> >
> > I think UAT is exactly this, you do not echaustively test an
application,
> > you make it jump through some predefined hoops, and then make a huge
leap
> > to......its probably good enough then.
>
> Psychotherapy...

what do you mean by Psychotherapy?

is it derogatory?

>
> >>>> But the jump from random behavior of people to random
> >>>> behavior of programs to too big too me. I do not believe it could be
> >>>> feasible.
> >>>
> >>> I do not see the problem.
> >>>
> >>> A team of mathematicians write formula to prove the twin prime
conjecture.
> >>>
> >>> P(team proves it) = P(the proof is correct).
> >>>
> >>> before observation of the proof.
> >>>
> >>> P(team writes some perfect code) = P(code is correct) (=0)
> >>
> >> Or
> >>
> >> Pr (Code is correct | Coin = Head) (:-))
> >
> > So you do not accept that the 'nature' of the programming team has any
> > statistical influence on the 'nature' of their output!?!
>
> No. What influence do you have on your date of birth? A program P is
either
> correct or not,

and a coin is either head or tails....so what, I can make massive
predictions about coin tossing.

> if we talk about an output. If you consider team outputs as
> a random variable [+the requirements (the problem) are fixed],

the requirements could be absorbed....like how the coin was
tossed....overarm? underarm?...it was just tossed.

> then it is a
> different thing. If so, then in my view the random component in output of
a
> team would be quite low. It wasn't so at the dawn of programming, but now
> things like typo errors have very low chance to slip undetected into
> delivery. So in my view the output might be uncertain, but not random.
This
> is why I wouldn't apply statistics here. The fuzzy set theory would fit
> much better here, IMO.
>
> > So there must be a model in my head, and yours that says that programs
are
> > not random, and that they are statistically dependent on the quality of
the
> > team.
>
> No, no. They are independent on anything. The number 1 does not depend on
a
> random generator that might time to time spit it out. [ The quality of the
> team describes nothing but its programmers. ]

OK we may as well agree to disagree....I am not with something here....or
you aren't.

the set { head, tails } is not dependent on a specific coin, yet the
probabilities of either result turning up is.

the set of programs is not dependent on a specific team, yet the
probabilities of a specifc one turning up is.

>
> >> No. Actually Pr (this proof is correct | good) = Pr (this proof is
correct
> >>| bad) = either 0 or 1.
> >
> > before observation it is not.
>
> Huh, the fundamental axiom of the probability theory is that observations
> do not influence the probabilities.

it doesn't.....but I think your interpretation is different to mine.

the observation does not influence the probabilities of an identical
experiment.....but they change the nature of the condition...

i.e.

P(throwing 6 on a dice) != P(throwing 6 on a dice | it's 6).

If you ask me to pick a card from a pack of cards, I wont be impressed if
you tell me the correct answer, given that you've seen the card.

The probabilities do not change......but the question has....i.e. all
probability is conditional, if you change the nature of the condition....you
change the question.....you change the answer.

>
> >> What you meant was probably:
> >>
> >> Pr (A randomly selected proof given by a Mr. Good is correct) >
> >> Pr (A randomly selected proof given by a Mr. Bad is correct)
> >
> > yes....I think.
> >
> >> This tells something about Mr. Good and Mr. Bad, but nothing about a
> >> concrete proof which is always either correct or not. To avoid
meaningless
> >> word games you have to present the set of outcomes. For example.
> >
> >> Consider
> >> the problem A and the set of all possible programs {Pq}. Then a P from
{Pq}
> >> either solves A or not.
> >
> > yes
> >
> >> Further you can talk about a set of teams {Xi} of
> >> programmers. The process is: you randomly select a team X from {Xi} and
> >> this team writes some P(X) which either solves A or not, i.e. A(P(X))
is
> >> either true or false.
> >
> > yes
> >
> > so lets have team that is always wrong, and one that is perfect.
> >
> > X0 and X1
> >
> > Pr(A(P(X0)) = true) = 0
> > Pr(A(P(X1)) = true) = 1
> >
> >> As you see it brings nothing. So you have (and you
> >> actually keep on trying to do it) to talk about some set of problems
{Aj}.
> >> Then you claim that if the team X is fixed and a problem A from {Aj} is
> >> randomly selected, then there is Pr(A(P(X)))= the probability that X
will
> >> solve a randomly chosen problem.
> >
> > so now lets have 2 problems A1 and A2, and we don't know the team i.e.
the
> > team is some Xi
> >
> > answers to A1 are P1 and answers of A2 are P2.
> >
> > Pr(A2(P2(Xi)) = true | A1(P1(Xi)) = true) = 1 !
> >
> > i.e.
> >
> > Pr(A2(P2(Xi)) = true | A1(P1(Xi)) = true) = Pr((A2(P2(Xi)) = true)
> > intersection (A1(P1(Xi)) = true)) / Pr(A1(P1(Xi)) = true)
> >
> > but
> >
> > A2(P2(Xi)) = true) => A1(P1(Xi)) = true)
> > and
> > A1(P1(Xi)) = true) => A2(P2(Xi)) = true)
>
> For any P1 and P2? There is no such team! (namely X1)

I know there is no such team....it's a theoretical problem.

>
> > => Pr((A2(P2(Xi)) = true) intersection (A1(P1(Xi)) = true)) =
Pr(A1(P1(Xi))
> > = true) = Pr(A2(P2(Xi)) = true)
> >
> > => Pr((A2(P2(Xi)) = true) intersection (A1(P1(Xi)) = true)) /
Pr(A1(P1(Xi))
> > = true) = Pr(A1(P1(Xi)) = true) / Pr(A1(P1(Xi)) = true) = 1
> >
> > so given an observation about one problem, we can deduce something about
> > another (based on a model about team Xi).
>
> Of course, if you know how A1 and A2 are related in terms of Pi(Xi) and
> Pj(Xj), then you could tell something about what would happen if you
> randomly select a team.

good....

> Though I do not see how this might help.

it might.....if you let it......

> Because
> judgement about similarity of problems is even more harder than judgement
> about a given program. It should be quite obvious, because the former is
> defined through the latter.

Programs are not defined in terms of problems....so I do not follow.

Seaching a list for the word A1 = "abc" is very similar to searching a list
for the work A2 = "bcd".

given the program is written by human beings, and they are hugely
predictable things, I would suggest there is a very high correlation between
team and program for problem A1 and A2.

>
> > (Its really is 15 years since I've done anything like this...and I
wasn't
> > that great at it at the time, so there may be a glaring mistake).
> >
> >> This value depends on the set {Ai} which
> >> fine structure is absolutely unknown. You can claim that An is similar
to
> >> Am, but where do you know it from?
> >
> > we do this every day.....
>
> Which at best proves nothing but our ignorance. We just do not know, so we
> are guessing. But from guessing to probability is a wast ocean of
knowledge
> we simply do not possess.
>
> > We do not need to know the whole set {Ai}, just those which we see in
> > everyday (experimental) life, in fact the nature of programming means
that
> > the Ai's may be highly correlated in a specific program....i.e. if the
data
> > access layer doesn't work, no access from the client, will work, so
these
> > 'problem' are in the real world highly correlated.
> >
> > A = false => B = false.
>
> As I said, that is guessing, which is even less likely to be right than
> guessing about program correctness. You can substitute (in LSP sense, mind
> you! (:-)) a more complex problem for a less complex one, that would not
> solve either.

?

component A is dependent on component B for behaviour X.

if B does not work then A cannot do X......that's not guessing.

My computer does not work if the fuse has blown.....is that guessing?

>
> >> That should follow from forall (good?)
> >> Xk there is a correlation between A(P(Xk)). Where that follows? This
all is
> >> built on the sand, you know.
> >
> > statistics generally are, but it only needs to be good enough.
>
> And good enough is quite precisely defined in Student-criteria and
> likewise. Applicability of those, first, requires some assumptions which I
> don't believe be satisfied, and secondly it requires sizes of statistics,
> you will never be able get.
>
> >> OK, if the program length is 2Mbytes then there are 2**(2**160)
outcomes.
> >> This is damn many.
> >
> > you are viewing the set of all programs (given a problem) as being
evenly
> > distributed....that may not be true.
>
> Which makes things only worse...

it may not be.....yet your skepticism overpowers all.

>
> > a normal distribution mean 0, variance 1.....the set of outcomes is the
set
> > R, but I can say 90% of the time it will be between (-1,+1).
>
> There are strong evidences that the distribution isn't normal.

it's an example...that the set of all outcomes does not tell you much.

> Should we
> map programs to the set of integer numbers by writing down the program's
> binary code, then it is quite obvious that the distribution will be
awfully
> bad.

sounds interesting....you could apply that sort of idea and get
incompleteness theorems....so it may not be as foolish as it looks.

you make the model after the observations.

If my computer is not on, and I try to run any program on it.....it wont
work.
I then get the model.

Power = off => for all P, P does not work.

> Maybe there are better mappings, who knows, but the problem of finding
> and evaluating them is in order of magnitude more complex than the two
> problems mentioned before.

if you accept the example, you accept it is theoretically possible, the rest
is 'belief', you believe it is impossible/impracticle to make any
statistical assertion about any useful set of programs (note a program can
be decomposed into subprograms...that may be very powerful).....I believe it
may be.

> We are mounting complexity over complexity, for
> nothing.

you have decided 'for nothing' without looking, you have decided god doesn't
exist without looking behind the door, it is the religion of the skeptic.

>
> >> I suppose it is much more than the total number of
> >> particles in the universe. You could claim that the distribution in
uneven,
> >> OK, you know which it is?
> >
> > no, run the experiment, make the observations, build a model, make
> > predictions, if it's evenly distributed your predictions wont be very
> > valuable, if it isn't, they will be.
>
> No chance.

can you give that some sort of probability?

> There is no need to try, because the size of any possible
> statistics will be too small.
>

so to test the function add with all the possible integers will give not
enough to draw conclusions about it's behaviour?

(2^16)^2....would it really take that long.....would it really matter if I
took a subset of (2^12) of them.

I would give you a very good statistical model...it may not exactly predict
the overflow point, but it would be pretty close.

> >>>> Even more difficult is to judge about its distribution.
> >>>
> >>> If the program is produced randomly yes, if it's produced by people
no.
> >>
> >> Maybe, but you do not know how people do it!
> >
> > I don't need to.
> >
> > I just need to observer they're previous outputs and see how they are
> > correlated (if at all).
>
> Sample size kills this too.

maybe we should move on..........we philosophically disagree.....

>
> >>>>> i.e. I can substiture complex for real
> >>>>
> >>>> You cannot in + : R x R -> R. But you can in Read : File -> R
> >>>
> >>> this is what's confusing to me.
> >>>
> >>> // dispatching on all parameters.....?
> >>
> >> Non-dispatching. With dispatching it would be better: you should not
> >> inherit R::+, that would be non-substitutable, but you could override
it
> >> with +: C x C -> C and so get it right.
> >
> > I'm still not 100% with this, you would probably take 10 minutes to
explain,
> > if we sat at the same keyboard and wrote some Ada.
>
> We could define "+" as follows:
>
> Left parameter: covariant
> Right parameter: covariant
> Result: contravariant, class-wide (=polymorphic type)
>
> So the profile will be:
>
> function "+" (Left, Right : Real) return Real'Class;
>
> Then when we derive Complex from Real, we have to override "+" three
times:
>
> function "+" (Left : Real; Right : Complex) return Real'Class;
> -- This deals with 1.0 + (3.0, 1.0)
> function "+" (Left : Complex; Right : Real) return Real'Class;
> -- This deals with (3.0, 1.0) + 1.0
> function "+" (Left, Right : Complex) return Real'Class;
> -- This is for (3.0, 1.0) + (1.0, 0.0)

so 4 implementations?

>
> With this "+" Complex will be substitutable for Real. For example in the
> program Sum:
>
> function Sum_Three (X, Y, Z : Real'Class) return Real'Class is
> begin
> return X + Y + Z;
> end Sum_Three;
>
> >>> is that sensible...or even correct terminology.
> >>>
> >>> number Add(number x, number y)
> >>> {
> >>> return x + y;
> >>> }
> >>>
> >>> in all context for real numbers...i.e, where + : R x R -> R goes to C
x C->
> >>> C
> >>>
> >>> void ClientAdd()
> >>> {
> >>> Real r1 = 1;
> >>> Real r2 = 2;
> >>>
> >>> Real r3 = r1 + r2.
> >>> }
> >>>
> >>> I can substiture complex for real (actually this is similar to the OP
> >>> question really).
> >>
> >> Yes, if +, =, 1 and 2 are dispatching (covariant). Then Complex r1 = 1
> >> dispatches to a correct "1" (1+0i), r3 = r1 + r2 dispatches to complex
> >> addition and then complex assignment and everything is fine.
> >
> > So it does work with my example?
>
> It could but you have to rewrite it to have substitution. There are the
> following possibilities for ClientAdd to do so:
>
> 1. Make it a template with a type parameter
> 2. ClientAdd have to be a member of Real. Then it will dispatch according
> to some actual parameter type.
> 3. ClientAdd have to be class-wide of Real. It works with all types
derived
> from Real, i.e. have a parameter of Real'Class type. In the body it will
> dispatch according to the actual parameter type.
>
> (1) is rather uninteresting, it is static polymorphism a-la cut-and-paste.
> For (2) or (3) we need some parameter to pass into ClientAdd and so
trigger
> substitution.
>
> >> But beware, it is not always possible to do. Consider:
> >>
> >> < : R x R -> Boolean
> >>
> >> We could not make it right, complex numbers are unordered!
> >>
> >> It is always so: you to gain something you have to lose something. That
> >> kills LSP.
> >
> > in the example it works because;
> >
> > there is a homomorphism between M from R->C
> > and another
> > inverse M : image(M)->R ?
> >
> > so inverseM(M(x)) = x...forall x in R.
> >
> > or am I still barking up the wrong tree.
>
> I think you are right. We found in C elements which "behave" exactly as
> some other elements from R *in* the program ClientAdd(). But we will not
be
> able to (1) find such for all possible programs and to

can we not say for all possible programs defined in R (and R only has 1
method '+').

Is there an example of a program here that we cannot substitute a C?

> (2) ensure that it
> will be the same homomorphism for all programs. (1)+(2) is IMO the essence
> of LSP subtyping.
>
which one the R-->C--->R one....can we not fix that for the set defined
above.