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, 05 Jun 1995 12:00:25 +1000 (EST) From: cmingins@insect.sd.monash.edu.au (Christine Mingins) Subject: Impending Eiffel Library Standard '95 To: nice-esg-libs@atlanta.twr.com Dear Committee Members A revised PELKS 8 document, (copy Bertrand's message below) acceptable to Tower SiG and ISE, is now available from the ISE ftp site. This document is intended to be the first public Eiffel Library Standard, to be announced at a press conference at Object Expo on June 7. Please review the document, and respond to me (or the committee) within the next two days, if possible. This document, while retaining most of PELKS 7, represents the results of intensive discussions, compromise and agreement between the compiler vendors in the past weeks, and I sincerely believe it will form a solid basis upon which the Library Committee can continue productive discussions for Vintage '96. Any comments you make will be given priority for ensuing committee discussions. (Of course if you all said "YES, it's Ok by me", that would be great!) Because time is so short, in parallel with your review and responses the Board will be taking a vote on accepting PELKS 8 as the Eiffel KLS vintage '95, so that the press conference on June 7 will have the official backing of NICE. These recent discussions and the outcome have not been intended in any way to take the place of the library committee process. Indeed, I agree with Steve Tynor's recent comment that it would have been better for this to have happened openly on the committee. Let's hope vintage '95 will be a good basis for the future. Christine ------------------------------------------------------------------ From: bertrand@vienna.eiffel.com (Bertrand Meyer) Subject: Revised document To: nice.lib@vienna.eiffel.com, Steve_Tynor@vienna.eiffel.com Copy to: From: Bertrand Meyer Mailer: BOOM I have revised the document (v. 8) and put it in the usual place. All the apparatus is there, i.e. a new README, the diff files (*-DIFF-7-8, *-DIFF-7-8.ps) etc. All the discussed modifications have been carried out with the following exceptions: - - I forgot to add the mention of provisional nature of FILE and STD_FILES. This will be fixed. - - Instead of `read_next_line' I used `to_next_line' as the new name for `next_line'. It struck me that `read_next_line' was confusing, as it suggested that a line is read, whereas all that happens is that input goes to the next line. What caught my attention is that there already is `read_line', which does what the name suggests. `to_next_line' is not ideal either as it does not suggest input. `input_to_next_line' is my current favorite. Any better suggestion? - - I did not remove the preconditions `readable' for file. I don't see how we can do without a precondition for input routines stating that the file is readable. My inclination would be to add `readable' as a query. Suggestions welcome. Best regards, - -- BM
Date: Mon, 5 Jun 1995 09:56:20 +0100 From: Paul Johnson <paul.johnson@gmrc.gecm.com> Subject: Serious library problem To: NICE-ESG-Libs@atlanta.twr.com Bertrand posted a note describing problems with `to_pointer' in STRING. I agree that to_pointer will have to be dropped from the PELKS. I seem to recall that in my Marconi kernel proposal I pointed out that language interfaces are inherantly non-portable, and hence should be left out of the standard. It is this kind of problem that I had in mind. I suspect there will be others (2D arrays anyone?). This problem applies to all classes with resizable storage areas, especially those which are going to be passed to C code. ARRAY is obviously going to be a victim, and most practical implementations of BIGNUM will also suffer. Hence we need a general solution. Bertrand's Proposal ------------------- Bertrand proposed that `to_pointer' should create a copy of the object storage and then free it when the foreign code no longer needed it. This solution has the advantage that the copy routine can do format conversions as well. Suppose that we want to pass Eiffel arrays to some language that expects arrays to carry size information in their header bytes (I suspect some Ada implementations will work this way). A copying solution could create this data structure irrespective of the underlying Eiffel structure. A reference-passing solution (see below) would only be able to pass the underlying Eiffel structure. This would constrain all Eiffel vendors to use a standard underlying structure, so that programmers would know what they were passing a pointer to. Even if the programmer knew that the Eiffel and the foreign language used the same structure, a change of foreign language compiler could break that. Hence I think that the main thrust of Bertrand's proposal is good. However I have some improvements to suggest. `to_pointer' versus `to_c' and `to_ada' --------------------------------------- I think that we should recognise that different languages have different data storage formats, and explicitly allow for these in the standard. As noted above, an allocate-and-copy system will allow format conversions for different languages. An Eiffel system may have to deal with more than one foreign language at a time, and being able to talk to all of them directly woud be a good thing. Hence I think that we should define a standard naming scheme rather than a set of standard supported foreign languages, rather in the manner that we already do for "external". All routines to convert to a foreign format would be of the form "to_X" where X is the foreign language, and all routines to convert from a foreign format would be of the form "from_X". The values of X supported by any given compiler would depend on the vendor. An implementation might not support any such data conversions, but would still conform to the standard. Aside: the Internet standards people have a similar concept: one possible status for an RFC is "if you do something like this, you should do exactly this". Different languages may have different memory allocation systems, and some foreign systems may even have garbage collectors. In the latter case the to_X routine may have to co-operate with the foreign garbage collector. For similar reasons it would be better to make deallocation part of the class that generated the object in the first place. We can then define routines of the form "free_X" which will deal with the foreign run-time in the same way as "to_X". If the foreign language uses an indirected data structure (e.g for multi-dimensional arrays) then the appropriate "free_X" routine will be able to handle this. Some runtimes will allow the addition of type information the data header, so that the Eiffel system can check that the correct free routine is being called for the type of data being deallocated. I do not see any reason to have more than one POINTER type: the POINTER type specifies that this is a foreign language pointer. AFAIK the only machine with more than one kind of pointer is the IBM PC (with its Tiny, Small, Large And Huge memory models). This is not so much a language problem as a hardware problem, and is probably best handled by specifying the target memory model in the "external" clause. Different Languages and Different Implementations ------------------------------------------------- A language such as Ada has many compilers, and it may be that not all these compilers agree about data structure formats. This might seem to require many different Ada conversion routines, e.g `to_ada_gnats', `to_ada_rational' etc. However in practice nobody is going to use more than one Ada compiler in a given project, even if they are using several different languages. Hence we only need `to_ada' and a compiler switch to specify the target Ada compiler. This can be left to the vendors. An Alternative Mechanism ------------------------ Another possible mechanism is to pass object storage by reference and lock the storage into one place in memory before doing so. This would be easiest if all such classes have a new ancestor with appropriate features. I'll give it the working name "INDIRECT". It will handle space allocation and resizing, and also convert its allocated space into a POINTER for interfacing to other languages. class interface INDIRECT feature lock is -- Lock data storage into one place in memory. ensure is_locked; unlock is -- Unlock storage from memory. Data may be moved or -- deallocated by GC. is_locked: BOOLEAN; -- True iff the object data is immovable in memory. to_pointer: POINTER; -- Return a pointer to the data storage area. require is_locked; end; This would not be perfect: storage could be unlocked before the C code has finished with it. However this is no worse than the need to deallocate storage once the C has finished with it, and avoids the need for copying. This would be more efficient than a copying method, but it fails to address the data format issue. Also some implementations would want to move the data into a special area, so that "lock" and "unlock" would perform a copy in any case. Hence I think that the allocate-and-copy solution is better. Paul. -- Paul Johnson | GEC-Marconi Ltd is not responsible for my opinions. | +44 1245 473331 ext 2245+-----------+-----------------------------------------+ Work:
Date: Mon, 05 Jun 1995 13:34:10 +1000 (EST) From: cmingins@insect.sd.monash.edu.au (Christine Mingins) Subject: Urgent, comment on PELKS 8 To: NICE-ESG-Libs@atlanta.twr.com (NICE-esg-libs ) Dear Committee Members A revised PELKS 8 document, (copy Bertrand's message below) acceptable to Tower SiG and ISE, is now available from the ISE ftp site. This document is intended to be the first public Eiffel Library Standard, to be announced at a press conference at Object Expo on June 7. Please review the document, and respond to me (or the committee) within the next two days, if possible. This document, while retaining most of PELKS 7, represents the results of intensive discussions, compromise and agreement between the compiler vendors in the past weeks, and I sincerely believe it will form a solid basis upon which the Library Committee can continue productive discussions for Vintage '96. Any comments you make will be given priority for ensuing committee discussions. (Of course if you all said "YES, it's Ok by me", that would be great!) Because time is so short, in parallel with your review and responses the Board will be taking a vote on accepting PELKS 8 as the Eiffel KLS vintage '95, so that the press conference on June 7 will have the official backing of NICE. These recent discussions and the outcome have not been intended in any way to take the place of the library committee process. Indeed, I agree with Steve Tynor's recent comment that it's a pity this couldn't have happened openly on the committee. Let's hope vintage '95 will be a good basis for the future. Christine ------------------------------------------------------------------------- From: bertrand@vienna.eiffel.com (Bertrand Meyer) Subject: Revised document To: nice.lib@vienna.eiffel.com, Steve_Tynor@vienna.eiffel.com Copy to: From: Bertrand Meyer Mailer: BOOM I have revised the document (v. 8) and put it in the usual place. All the apparatus is there, i.e. a new README, the diff files (*-DIFF-7-8, *-DIFF-7-8.ps) etc. All the discussed modifications have been carried out with the following exceptions: - - I forgot to add the mention of provisional nature of FILE and STD_FILES. This will be fixed. - - Instead of `read_next_line' I used `to_next_line' as the new name for `next_line'. It struck me that `read_next_line' was confusing, as it suggested that a line is read, whereas all that happens is that input goes to the next line. What caught my attention is that there already is `read_line', which does what the name suggests. `to_next_line' is not ideal either as it does not suggest input. `input_to_next_line' is my current favorite. Any better suggestion? - - I did not remove the preconditions `readable' for file. I don't see how we can do without a precondition for input routines stating that the file is readable. My inclination would be to add `readable' as a query. Suggestions welcome. Best regards, - -- BM
Date: Mon, 5 Jun 1995 09:15:44 +0100 (BST) From: S M Fisher <S.M.Fisher@letterbox.rl.ac.uk> Subject: Urgent, comment on PELKS 8 To: NICE Library Committee
Date: Mon, 05 Jun 1995 23:57:29 +1000 (EST) From: cmingins@insect.sd.monash.edu.au (Christine Mingins) Subject: Voting reminder To: NICE-ESG-Libs@atlanta.twr.com (NICE-esg-libs ) Voting, Library Committee Chair ------------------------------- There were two nominations: Paul Johnson Christine Mingins Voting ends 12 June, midnight each member's timezone -- Christine
|
|
