From Craig.Dedo@mixcom.com Fri Feb 2 05:22:38 1996 Received: from mixcom.mixcom.com (mixcom.mixcom.com [198.137.186.100]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id FAA09171 for ; Fri, 2 Feb 1996 05:22:30 +0100 Received: from 156.46.42.202 by mixcom.mixcom.com (8.6.12/2.2) id WAA16063; Thu, 1 Feb 1996 22:23:16 -0600 Message-Id: <199602020423.WAA16063@mixcom.mixcom.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 01 Feb 96 19:39:43 -0600 From: Craig Dedo Subject: Re: (SC22WG5.1022) (x3j3.1996-41) Re: fodder for meeting To: Keith.Bierman@eng.sun.com Cc: WG5 Mailing List X-Mailer: SPRY Mail Version: 04.00.06.17 Dear Keith: On Wed, 31 Jan 96, Keith.Bierman@eng.sun.com wrote: > >> I may be wrong on this (Stan Whitlock or Steve Lionel can correct >>... >>thru regular RMS file calls and therefore supports all of the >>(elaborate and complex) RMS file structure. The OpenVMS RMS file > >Questions of formatting beyond 80 columns aside, the point of this >escapes me. RMS is a fine file system. However it has nothing to do >with the C standard. That some implementation can "get it right" isn't >really the question. It can be done. It has been done. It will be done. I attempted to provide a counter-example to Jerry's assertion that C files do not have record structure. That was the point. It shows that not all C files lack record structure. Jerry may be correct if he is willing to amend his statement to say, "There could be a possible C interoperability reason for removing the INQUIRE statement restrictions, since _MOST_ C files do not have record structure." However, I will not attempt to put words in Jerry's mouth. That would be most unwise. >> If this is true, we should fix the problem ASAP. The purpose of >>ANY programming language is to support the developoment of practical >There are many practical applications which are not easily coded in >Fortran. That doesn't mean that we have to add the functionality of >LISP, Sybase and multimedia authoring systems. All address useful and >practical problem domains. I agree with you that none of these are areas for Fortran. > >Large files are important, but that aren't worth tossing aside the >state of the standard for. And, as previously mentioned, there is >nothing to stop implementations from getting it right. The problem is >that there is nothing in the Standard to force it, and many solutions >may be non-portable. Which is precisely why I believe that we should fix it ASAP using the best means available. I did NOT say that we should stop the finalization of Fortran 95 before this is fixed. >How many users have applications which deal with such large files? How >many of the people with such problems mind a bit of non-portability >(which they have in spades anyway?). The one data point provided, >AMOCO, wasn't upset. Why are you? Do you own a system which could deal >with such a large file? Have you ever worked on such a project? Until >now did you realize such applications existed? (I can probably answer >yes to all three, for some version of "yes") To the last 3 questions: No, No, and Yes. To the first two: I do not know. Why am I concerned? Because I believe that it is not good language design to tolerate such unnecessary irregularities and gotchas. If people discover a problem like this we should move with all deliberate speed to have get it resolved. That does NOT means that we need to hold up F95. >Creating a new process is absurd. We have corrigenda. We have >balloting. If this really were a fatal problem, we'd make it a country >position to fix it, and delay f95. It isn't that bad. >Getting a new formal process started would take longer than the delay >would entail. Getting yet another informal process would accomplish ???? I threw that out as a raw idea, to get people thinking about how to best solve the problem. Perhaps Miles has some ideas on the best process to use. ---------- Sincerely, Craig T. Dedo Internet: Craig.Dedo@mixcom.com Elmbrook Computer Services Voice Phone: (414) 783-5869 17130 W. Burleigh Place Brookfield, WI 53005 Disclaimer: These opinions are mine alone. USA They do NOT represent any organization. "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin