Re: [Liberty-eiffel] I dont agree with that error

[José Bollo]

Le Mon, 06 Jan 2014 10:23:18 +0100,
Raphael Mack <address@hidden> a écrit :

> Hi,
> 
> I'd like to investigate into this, but I don't yet understand the
> intention of the original commit which introduces the problem. Could
> you elaborate here? - Just reverting these changes would probably
> help to fix Josés compile issue, but Frederic (he is zen, right?)
> didn't add this check just for fun...

Hi, happy new year! Gute neue jahr! Buon anno!

I suspect that the targeted problem is the generic derivation for
constrained formal arguments. As you know, expanded (INTEGER for
example) can be used for instanciation of a constrained formal class of
a generic (HASHABLE or COMPARABLE for example). Then the question is
what feature to call ('hash_code' or 'infix "<"' for example). In the
precise case of repeated insert, no answer can be said! So this is why
zen enforced that rule. That's what I suspect. 

Very very happy to see that you plan to work on that. Danke sehr.

José


> 
> Cheers,
> Rapha
> 
> Am Freitag, den 13.12.2013, 23:01 +0100 schrieb José Bollo:
> > Le Thu, 12 Dec 2013 14:01:24 +0100,
> > Cyril ADRIAN <address@hidden> a écrit :
> > 
> > > Hi José,
> > > 
> > > 2013/12/11 José Bollo <address@hidden>
> > > 
> > > > It works very well with SmartEiffel but adler doesn't want to
> > > > compile it. It argues that at least one conforming path must
> > > > exist. Why? I can't agree. From ECMA page 94, the validity rule
> > > > VMRC also disagree.
> > > >
> > > > So Why? What is the good reason that I don't know?
> > > >
> > > 
> > > You are right, that is strange. It comes from the never-released
> > > SmartEiffel 2.4 codebase
> > > (r8513<https://gforge.inria.fr/scm/viewvc.php/trunk/tools/kernel/feature_accumulator.e?root=smarteiffel&view=diff&r1=8512&r2=8513>),
> > > the log is "Checking for situations that can lead to ambiguous
> > > feature calls".
> > 
> > That's good it means that I will have satisfaction. When?
> >  
> > > The problem is a technical one and the solution is not good
> > > because it forbids valid use cases and does not fix actual
> > > problem (see TEST_INHERIT2).
> > 
> > Yes I see...
> > 
> > Thanks.
> > Regard
> > 
> > > 
> > > Cheers
> > > 
> > 
> 
> 
>