Re: self initializing types and SPECIAL
|
|
helmut.brandl
|
Hello Simon,
thanks for responding. Below some comments. It seems that our opinions converge ... ;-) Regards Helmut The Eiffel Compiler http://tecomp.sourceforge.net Simon Hudon wrote: > Hi Helmut, > > Sorry I took such a long time to respond but I've been thinking about > your email so as to send you something that makes sense. > > On 14-Sep-08, at 5:21 PM, Helmut Brandl wrote: > >> Let me make some general remark to the point, on which we had >> different opinions. The question is: Is SPECIAL sufficient as a >> kernel class or do we need something like SPECIAL_SEQUENCE? >> >> You voted for the former, I for the latter. >> >> If think we basically agree, that the question is interesting only in >> case of types which are not self initializing. Let me try to >> implement ARRAYED_LIST on the basis of ARRAY (which is itself based >> on SPECIAL). We will get something like (glossing over some details) >> >> class ARRAYED_LIST[G] inherit LIST create with_capacity feature {NONE} >> arr: ARRAY[?G] >> with_capacity ( cap: INTEGER ) >> do >> arr.make(0, cap-1) >> end >> feature >> count: INTEGER >> capacity: INTEGER do Result := arr.count >> item alias "[]" ( i: INTEGER ) : G >> require i < count >> do >> check {arr_result: G} arr[i] end -- <--- that is the >> crucial point >> Result := arr_result >> -- alternatively you can use: >> -- local res: ?G do res:=arr[i]; check res/=Void end; >> Result:=res end" >> end >> all_elements_in_the_list_attached: BOOLEAN >> do >> ... -- straightforward loop from 0 to count-1 with void >> test >> end >> ... >> invariant >> 0 <= count >> count <= capacity >> all_elements_in_the_list_attached >> end >> >> You can play a little bit around with it. But without having >> something like SPECIAL_SEQUENCE you need the object (or void) test in >> an assertion. >> >> What if assertion monitoring is off? >> Alternative a: use a void test instead of an object test local and >> ignore the assertion at runtime. Consequence: We have lost void safe >> Eiffel (note: your code might be buggy and the returned item is >> void). I.e. the compiler cannot guarantee, that there are no void >> calls during runtime. >> >> Alternative b: Even if assertion monitoring is off, assertions >> containing object/void tests will be executed at runtime. (Manu told >> me, that this is the current view of the ECMA committee). But the we >> have lost void safety as well. We have improved the situation a >> little bit, because we would not get a call on void target but an >> assertion violation. But the consequence is the same. The compiler >> cannot guarantee void safety. >> >> I am convinced that in the end neither of the two solutions will be >> chosen by the ECMA committee. >> >> My opinion: They will forbid void/object tests in assertions in the >> long run and come up with something like SPECIAL_SEQUENCE. >> >> Reason: void/object tests in assertions are just a transitional >> vehicle between etl2 and etl3 (don't get me wrong; it is a good >> vehicle, because it allows introduction of attached/detachable types >> without breaking code). In code written completely in etl3 they are >> not necessary. It is sufficient to have them in control flow >> statements like conditionals and loop exit conditions (and they are >> necessary for the silly workaround for not having a class like >> SPECIAL_SEQUENCE ... ). >> >> > > There actually is one good point of keeping those assertion when > assertion monitoring is off: there it creates a punctual transition > between a section where an entity can be detached and a section where > it cannot and it allows us to get rid of most the void checks. So, > even for several calls on an attached reference, there would only be > one check which would ensure that the reference is not misused instead > of having one check at each call. you. Void tests or object tests are needed in assertions and not only in flow control statements as I stated in my previous posting. So I changed my mind. I agree also in keeping assertions with void/objects tests, even if assertion monitoring is off. This is crucial for having void safety. So calls on void targets will be converted to violated assertions. The compiler can then guarantee that there are no calls on void targets, but he cannot guarantee that there are no violated assertions. This is still an improvement over non-void-safe Eiffel, because, as you have already stated, the assertion checking is done only once, the avoided void checks can be many. > > I must admit that I'm wondering whether the whole attached/detachable > and object tests idea is premature. A sound Eiffel type theory would > certainly have prepared the terrain better. I understand though that > it is not always realistic to wait an eternity for a proper theory but > the solution that works around the problem can only be a temporary one > without proper back up. I am convinced that void safety in Eiffel is an improvement. Some details still need to be worked out (e.g. assertion monitoring with object/void tests). I am just disappointed that the promoters of ECMA Eiffel are not willing to discuss the issues and are not willing to publish their thinking about the issues. Either they do not work at all or they hide themselves in their ivory tower, thinking that outsiders cannot contribute (sorry for the sarcastic comment). > > > In this case, NONE used to be the bottom of the inheritance graph but > it is not true anymore if we still consider Void to be its only > element. What we must do, then, is to elect a new bottom which would > be an empty type and consider NONE as a singleton type which can be > joined to any other type to get a detachable type. While we're at it > why not allow the join of any two types? The complete (algebraic) > simplification could prove to be very powerful. But I digress. > > In summary, I agree that attached and detachable types along with > object tests introduce some complications (as does the introduction of > any new language construct). This is not an improvised construct (it > seems to go back at least ten years since the first publication on the > subject) and the only thing that could make its integration smoother > is having a sound theory for the whole type system. > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ freeelks-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/freeelks-devel |
||||||||||||||||
Colin Paul Adams
|
>>>>> "Helmut" == Helmut Brandl <[hidden email]> writes:
Helmut> just disappointed that the promoters of ECMA Eiffel are Helmut> not willing to discuss the issues and are not willing to Helmut> publish their thinking about the issues. Either they do Helmut> not work at all or they hide themselves in their ivory Helmut> tower, thinking that outsiders cannot contribute According to Manu, it is the latter (that is the reason he gave me for not publishing the minutes). -- Colin Adams Preston Lancashire ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ freeelks-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/freeelks-devel |
||||||||||||||||
|
helmut.brandl
|
Colin Paul Adams wrote:
>>>>>> "Helmut" == Helmut Brandl <[hidden email]> writes: >>>>>> > > Helmut> just disappointed that the promoters of ECMA Eiffel are > Helmut> not willing to discuss the issues and are not willing to > Helmut> publish their thinking about the issues. Either they do > Helmut> not work at all or they hide themselves in their ivory > Helmut> tower, thinking that outsiders cannot contribute > > According to Manu, it is the latter (that is the reason he gave me for > not publishing the minutes). > deserves. Great invention but poor ... I hope that it will change in the future, because I have invested some time in Eiffel. I don't want to loose that investment. Helmut The Eiffel Compiler: http://tecomp.sourceforge.net ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ freeelks-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/freeelks-devel |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
