lothar scholz

This leaves the question open if this is a good or bad thing.
I'm afraid it is the latter, because it is just the usual way from a
company to say that they will not maintain anything anymore. Hoping to
find people to do it for free.

And i doubt that the eiffel community is large enough to do this. All
the 50 persons who are seriously using eiffel worldwide seems to have
something else to do.

So i think in a year we can reduce the list of eiffel compilers to ISE
(expensive) and SmartEiffel (pure research without backward
compatibilty).

Sounds pessimistic ? Yes it is.

philippe ribet

Hi Roger,

I suggest you to read the paper jot2004.pdf carefully again. Choice is
*NOT* nonvariant/covariant/contravariant. SmartEiffel proposal *is not*
contravariant, SmartEiffel is covariant everywhere because is a
covariant language.

SmartEiffel just use some different conformance rule from ESI. Please
take some time until you deeply understand the independance from
variance and conformance, and how one definition use other. Variance and
conformance are use in two very different situations.

Best regards,

--
Philippe Ribet

The README file said
"Requires Windows 95, NT 4.0, or better."
So... I installed it on Linux!

philippe ribet

While you use "contravariant" I'll still consider you didn't understood
the discussion because you confuses two concepts: conformance and variance.


Please, let me explain one last time with simple examples.

Conformance is a property which means "is a [sort of]".
This property does not depend on syntaxical rules, alphabetical order of
the type names or ... It only depends on the semantic you want to put on
your types and on your system.

For example, you want APPLE "is a [sort of]" FRUIT. This is a design
choice and you need it from a semantic point of view. This choice is not
covariant, it is not contravariant. This choice is just the conformance
direction you choose to be able to write "fruit := apple".

To be more abstract, given two types T1 and T2, you can either choose T1
"is a sort of" T2 or T2 "is a sort of" T1 or they are independant. This
choice only depends on T1 and T2 semantics. Depending on you choice,
you'll be able to write t2 := t1 or t1 := t2 or neither of them.

Now, consider two types A and F with the following semantic:
- type A models procedures which accept apples as parameter
- type F models procedures which accept fruits as parameter

We have to decide if (1) A "is a [sort of]" F or if (2) F "is a [sort
of]" A.

(1) a procedure accepting apples is a procedure accepting fruit
No!
This is clearly wrong because if it is accepting apples, it won't be
valid to handle fruit.

(2) a procedure accepting fruit is a procedure accepting apple
Yes!
Of course, if it accepts fruit, then apple will be accepted because
apples are fruits.

From all procedures accepting apple, those accepting food and those
accepting fruits are one of them.

So, from *semantic considerations* we choose (2) as conformance direction.

Translating this into EIFFEL syntax:
f:PROCEDURE[ANY, FRUIT] is a a:PROCEDURE[ANY, APPLE]
which means you can write "a := f"

It's not covariant nor contravariant, it's just the assignment direction
definition. It's only because we decide conformance that we are able to
make assignments.

Please note that ESI implementation is based on the opposite definition.
That means they answer yes to (1) and no to (2)!!! You can see how they
are wrong. Until now, they refused to fix this because they do not want
users have to fix code...


Sorry, I don't know the latest ECMA choice.


I can't explain in a simpler way and I can't understand how to give
different answers to (1) and (2). Why does some people need many years
to understand this, once clearly exposed?

Hope this helps,

--
Philippe Ribet

The README file said
"Requires Windows 95, NT 4.0, or better."
So... I installed it on Linux!

peter van rooijen

Hello Philippe, Roger,

Philippe, could you explain how what you describe is *not* contravariant?

Of course (;-)) the mechanism you describe as the one to be preferred
*is* contravariant: conformance varies (narrows/widens) for procedures
in the opposite (contra) direction of the conformance of their parameters.

Perhaps you have some very specific conception of what the term
"contravariance" means, possibly because you picked up that term is a
specific context. Perhaps your interpretation is not the only good one,
or even the most reasonable one?

Of course I don't know why each of you think what you think or say what
you say :-). It just seems to me that the (slight) antagonism is
completely unnecessary. Specifically, I agree with Roger that use of the
qualification "contravariant" for your proposed conformance rule does
*not* indicate a lack of (deep or otherwise) understanding.

Please consider that what I say might in fact be accurate and/or useful.
I personally believe it might be ;-).

Just one more question (at the risk of throwing oil on the flames :-)):

Why do you believe that that is the reason why they, as you said,
"refuse to fix this"?

Please note the smileys and winkeys I interjected. I would like the
intelligence of all you guys to work together; it seems to me that you
have many common interests.

Have a nice day!

Peter

P.S. In programming Smalltalk, I enjoy daily the bliss of
universal/dynamic conformance. If it works, it is correct :-).

philippe ribet

Just because when you decide that some class A conforms to some class B,
then this does mean nothing to say "this is a covariant choice" or "this
is a contravariant choice". Just because there is no such thing like the
standard direction or the opposite direction.

So "some class A conforms to some class B" is just a design choice
related to semantic you want.

Variance is related to type variation in feature redefinition (this mean
in sub-type). Here, there is no feature redefinition, it's just type's
assignement rule (named conformance).


Please, just tell me what you think about the follwing sentence:
"a procedure accepting apples is a procedure accepting fruit".

Give your opinion about this sentense please.

I hope vocabulary is more clear now, then it's easier to discuss ;-)

Best regards,


--
Philippe Ribet

The README file said
"Requires Windows 95, NT 4.0, or better."
So... I installed it on Linux!

peter van rooijen

Hi Philippe,

I don't see how this relates to the discussion other than confirming the
suspicion that you attribute a very narrow meaning to the word
'variance' and its variations (;-)).

It seems to me that in Eiffel it is more than just a design choice. If
you want the type of class A to conform to that of B, you'll have to let
A inherit B. So there is an implementation constraint as well.

But again, this is not directly relevant to the discussion, AFAICS.

This is where you are mistaken. The term 'variance' means much more than
the narrow meaning you ascribe to it. Roger said essentially the same
thing, so perhaps you will entertain the possibility that it might in fact be so.

You did not answer my question, which is unfortunate, so I will ask you
again if you might want to state the reason for your belief. If you
choose not to do that, that is fine too.


Oh, I agree with your analysis. I read the article in question some time
ago and I agreed with it then.

What I don't agree with is that attaching the predicate 'contravariant'
to your proposed solution is incorrect, or worse, implies a lack of understanding.


Of course clear vocabulary helps the discussion. At the same time the
discussion in this thread is about vocabulary much more than about what
the rules for agent conformance should be.

On the latter point, I don't see disagreement between you or Roger or
myself.

The only real disagreement is about whether it is up to you what the
words 'variance', 'covariance', 'contravariance' mean.

That is, however, not a really important issue and now that it is
perfectly clear, there really isn't much more to say about it :-).

Cheers,

Peter

eric bezault

In this message I will use "SmartEiffel's implementation" and
"ISE's implementation" instead of "covariance/contravariance"
or "reverse conformance" in order to avoid a terminology war.

The problem with SmartEiffel's implementation is that (2) is
not just "open arguments" but "open operands", in other words
the target can also be open.


Let's consider the following classes:

class ANIMAL
feature
eat (f: FOOD) is do ... end
end

class COW
inherit
ANIMAL
redefine
eat
end
feature
eat (f: GRASS) is do ... end
...
end

Now let's have this routine:

do_something (p: PROCEDURE [ANY, TUPLE [COW]]) is
local
my_cow: COW
do
create my_cow
p.call ([my_cow])
end

In SmartEiffel's implementation it is valid to write:

create meat
do_something (agent {ANIMAL}.eat (meat))

ending up trying to make a cow eat some meat at run-time.
ISE's implementation rejects this code at compilation time.

That was with an open target. Now with open arguments let's
have this other routine:

do_something_else (p: PROCEDURE [ANY, TUPLE [FOOD]]) is
local
my_meat: MEAT
do
create my_meat
p.call ([my_meat])
end

In ISE's implementation it is valid to write:

create cow
do_something_else (agent cow.eat)

ending up trying to make a cow eat meat at run-time.
SmartEiffel's implementation rejects this code at
compilation time. In defence of ISE's implementation
it should be said that their feature `call' has a
precondition, and therefore correct code should
actually look like that:

my_operands := [my_meat]
if p.valid_operands (my_operands) then
p.call (my_operands)
else
-- try to call `p' with invalid operands
end

so in practice the cow should never eat meat at run-time.
But this is relying on run-time checks, which is not
fully satisfactory, especially for a statically typed
language like Eiffel.


In any case, even though SmartEiffel's implementation
looks very promising and more flexible, it seems that
both implementations have type holes. These type holes
are very similar to CAT-calls (we can actually consider
them as a derived version of CAT-calls). Note that in
both examples above the CAT-call detector implemented
in Gobo's gelint will report the potential problem.

--
Eric Bezault
mailto:ericb@gobosoft.com
http://www.gobosoft.com

damien.guichardwanadoo.fr

let me tell you the great story of the liberation of EIFFELAND (not to be
taken seriously).

- THE CLIENT
freedom for every TUPLEs in the world!

- THE SUPPLIER
don't worry! we will "recast" you into productive TUPLE citizens.

then security is restored, all dissident TUPLEs are arrested and go to
jail..
but, when amnesty is granted, they can't be liberated because the keys are
too flexible.

- damien

philippe ribet

Your example is too complex! It just explains CAT-call problem wich is
Eiffel relative and not implementation nor agent relative.

Agents are just delayed calls. Using imediate calls, your example is:
animal := my_cow
animal.eat(meat)

"ending up trying to make a cow eat some meat at run-time"

Of course we can add some new rule to avoid such assignment and the
result will be SE's "implementation rejects this code at compilation
time". So we will have the same good properties with every object types
that ISE has with agent type.


--
Philippe Ribet

The README file said
"Requires Windows 95, NT 4.0, or better."
So... I installed it on Linux!