NICE Eiffel Standards Group -- Library Committee Mailing List To post to list: NICE-ESG-Libs@atlanta.twr.com To send mail to the Chairman of the committee: NICE-ESG-Libs-chair@atlanta.twr.com Administrative matters (sign up, unsubscribe, mail problems, etc): NICE-ESG-Libs-request@atlanta.twr.com
Date: Mon, 20 Mar 95 18:53:17 PST From: bertrand@vienna.eiffel.com (Bertrand Meyer) Subject: A bug in the PELKS and a correction To: nice.lib@vienna.eiffel.com Copy to: From: Bertrand Meyer Mailer: BOOM Dear colleagues: One of our users has found a bug in the PELKS assertions for `deep_equal'. The problem is the postcondition clause labeled `same_type' which has been introduced in version 6. (It's nice to have a copy with change bars, by the way.) The postcondition reads same_type: Result implies some.same_type (other) This is only correct if `some' is not void. We propose correcting this bug as follows: (1) Adding a new clause both_or_none_void: (some = Void) implies (Result = (other = Void)) (2) Rewriting the offending clause `same_type' as same_type: (Result and (some /= Void)) implies some.same_type (other) We have applied these corrections to the ISE implementation of the library, (since we feel it is better to be correct than standard!). We think these corrections should also be applied to the PELKS. Christine, would you please look at the issue and decide what to do (start a discussion, start a vote on the above correction, accept it as a bug fix without a vote)? Thanks and best regards, -- BM
Date: Mon, 20 Mar 95 17:30:01 PST From: dinov@geneve.eiffel.com (Dino Valente) Subject: My Vote To: NICE-ESG-Libs@atlanta.twr.com Here are my votes: MOTION VOTE ---------------------------|---| LIB95-PAJ-PART_COMPARABLE |NO | ---------------------------|---| LIB95-PAJ-COMPARABLE |NO | ---------------------------|---| LIB95-TWR-HASHABLE |NO | ---------------------------|---| LIB95-TWR-HASHABLE2 |NO | ---------------------------|---| Dino Valente
Date: Mon, 20 Mar 95 18:04:27 PST From: bertrand@vienna.eiffel.com (Bertrand Meyer) Subject: The current proposals To: nice.lib@vienna.eiffel.com Copy to: eiffelgroup Christine_Mingins From: Bertrand Meyer Mailer: BOOM Only today did the ISE team have an opportunity to study in detail the current proposals. I vote NO on all of them and hope the hashing proposals are defeated or delayed, as passing them would be a disaster for the Eiffel community and would essentially kill any hope for an Eiffel library standard in the next two years. The major problem is that no one paid any attention to compatibility with existing implementations. (At least this is the favorable interpretation.) Passing the hashing proposals would break every existing Eiffel system (at least every ISE Eiffel system, but I suspect others as well). Not content with breaking existing systems, the hashing proposal is perverse enough to reuse an existing feature name, `hash_code', thus ensuring that thousands of users will have to write dozens of `select' clauses! This is rather sadistic. This is all the more unacceptable that in the current library there is a trivial way to obtain the desired effect: include in class ANY a featured called e.g. `hashed' (NOT `hash_code'!) which does the job. There will be no standard unless proposers of new facilities show a minimum of respect for other implementors and, more importantly, existing users. The proposals are all the more regrettable that, given some time to devise a suitable transition mechanism, some of the suggested changes do appear technically attractive if (1) they are thoroughly explored theoretically and validated practically by a pilot implementation, (2) the concerns of current users are properly treated and (3) a smooth transition path is charted. But not for vintage '95! The Tower proposals represent the following approach: (A) Use the standards process to introduce sweeping changes from existing implementations. As a result, we may have a beautiful paper standard, but implementations take years to catch up. In the meantime, everyone suffers: implementors who have to change everything all the time and, more importantly, large users who convert, convert and re-convert. This is a subversion of the standards process. Standards are not meant to invent but to codify existing practice. What we are promoting (and everyone I have talked to seems to agree) is the polite and effective approach: (B) Take the subset of current practice that every implementation can include NOW (meaning in the version that will reach users later in 1995) and define it as the library standard, vintage 95. The library committee and NICE should adopt approach (B), the consensus approach; (A), in contrast, is the divisive approach, which can only create endless squabble and, in the end, the failure of the standards process. Approach (B) is realistic today because there is nothing, in the current PELKS, that is known to make it difficult for any vendor to implement. That is why we should take the PELKS and use it as vintage 95. If someone finds an exception to the first sentence in this paragraph, i.e. something that seems to make it difficult to implement for compilers other than ISE's, then he should point it out so that we can discuss it and, if necessary, amend or remove it. This process can take but a few weeks, meaning that we can all have standards-conformant compiler on users' desks IN A FEW MONTHS. After that we should discuss extensions and changes, but discuss them seriously. A proposal of the form ``Here is our new version of hashing, it has no connection whatsoever with what was there before [and, unsaid, it makes it impossible for ISE to provide a smooth transition path to its users], vote yes or no for March 20'' is not the right way to go. The issues are too subtle for e-mail discussions; as Steve Tynor mentioned a few weeks ago we need to have real technical meetings (and we are again offering to host such a meeting in Santa Barbara or Paris, whichever is more convenient to a larger number of people). My feelings about Paul Johnson's proposals are less strong, but I still vote against both of them because they appear unjustified: - On PART_COMPARABLE: the library standard is not a theory of mathematics. It should be minimalist. COMPARABLE is there for a reason: it is needed to describe other, directly useful kernel library classes such as INTEGER, STRING etc. This is not true of partial order relations. If we include them, we should also do the whole of Bourbaki - transitive relations, preorders, symmetric relations, reflexive relations... Where do we stop? - On COMPARABLE (other than the point about min and max for equal values, for which I think either convention can be justified), I disagree with Paul's notion of equality. There is no need for a separate order_equal. I had long discussions on this point with Michael Schweitzer on this point last summer and (although I don't know whether I managed to convince him) I think `order_equal' is just `equal'. More generally these are again pretty big changes which, if at all, should be considered for vintage '96. Let's not reinvent the world; let's codify existing practice so that we can guarantee a basic level of interoperability to our users NOW. And let's show some respect for the installed base. -- BM
