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, 03 Jul 1995 22:22:14 +1000 (EST) From: cmingins@insect.sd.monash.edu.au (Christine Mingins) Subject: Language/Library Overlap To: NICE-ESG-Libs@atlanta.twr.com Dear Committee Members, Neil Wilson from the Language Committee is in the process of updating Eiffel: The Reference. I include a recent message from him suggesting that BOOLEAN and operations on bit sequences be moved into the Kernel Library domain. Please give his concerns your consideration. I attach his note below. Regards, -- Christine ------------------------------------------------------------------------ Christine, I don't know whether you're aware, but I've been tasked with updating Eiffel: The Reference. (Actually I asked for it - probably in both senses of the term ;-). One of my concerns (besides the immensness of the task) is the language/ library border. Unfortunately due to the fact that they have been separated and are dealt with by two separate committees, both with their own agenda, there is little cross border traffic. This may cause problems if we don't keep on top of it, particularly since there are a few issues which will require the border to be moved slightly. I am currently working on the expression mechanisms. The language as currently defined lists the evaluation results of several of the operators in class BOOLEAN (23.8). It is my view that the results of the standard BOOLEAN operators is a matter for the library definition. The only assistance required from the language is to ensure that BOOLEAN semi-strict operators do not evaluate the second operand if not required. I intend to strike the redundant section from the language definition. My question is are we _sure_ that the axiomatic definition of class BOOLEAN will lead to the standard interpretation and _only_ that interpretation. I reckon it does, but I'd feel happier if one of the resident logicians gave me the nod. (BTW infix "xor" ind infix "implies" lack 'result_exists' post-conditions in class BOOLEAN). The other issue which I would suggest falls more into the library arena than language is the definition of the operations on Bit sequences. Again the language attempts to define some operations (23.11). This is not as extensive as the operations defined in ETL 32.10. Can I suggest that you look at the BIT_N template as you would any other class and include it in the library kernel and its hierarchy. This is now the only 'class' required by the language that doesn't have an ELKS accepted definition and will become a sticking point if it isn't resolved soon. Regards -- Neil Wilson (neil@aldur.demon.co.uk) ...Arrive without travelling, Ossett, Yorkshire, UK see all without looking...
