From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!attcan!uunet!husc6!rutgers!rochester!pt.cs.cmu.edu!sei!sei.cmu.edu!firth From: firth@sei.cmu.edu (Robert Firth) Newsgroups: comp.lang.ada Subject: Re: Ada/UNIX(tm) and the NAME function Message-ID: <8069@aw.sei.cmu.edu> Date: 21 Dec 88 19:43:16 GMT References: <920005@hpcljws.HP.COM> Sender: netnews@sei.cmu.edu Reply-To: firth@bd.sei.cmu.edu (Robert Firth) Organization: Carnegie-Mellon University, SEI, Pgh, Pa List-Id: In article gary@milo.mcs.clarkson.edu (Gary Levin) writes: >In article <8008@aw.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes: > ... > The best, in my opinion, is to have the semicolon optional: a newline > will terminate the statement if possible. So you can write > > x := x+1 > y := y+1 > > and it works, but > > x := a0+a1+a2+ > a3+a4+a5 > > also works. One hardly ever gets this wrong. > >However, if you are in an expression oriented language, it is possible >to get really strange effects here. I would write the above statement >as: > > x := a0+a1+a2 > +a3+a4+a5; > >Having submitted this to Icon, I found that the program didn't work as >expected. It took me quite a bit of debugging to find that this was >being treated as two statements, and so x was only assigned a0+a1+a2. >Further, I then tried to write this as > > x := (a0+a1+a2 > +a3+a4+a5); > >and I was informed that I was missing a right parenthesis after a2 >(and before the inserted semicolon). Note that Icon would correctly >handle the case of the trailing + as Firth wrote his example. > >Generally, I prefer systems that have me say what I mean, rather than >guess. And if they must guess, they should have the grace to indicate >their guesses. > >It is certainly possible that Icon no longer suffers from this >particular lexical/syntactic quirk; I haven't used it in quite a while. >-- > >----- >Gary Levin/Dept of Math & CS/Clarkson Univ/Potsdam, NY 13676/(315) 268-2384 >BitNet: gary@clutx Internet: gary@clutx.clarkson.edu Newsgroups: comp.arch,comp.lang.fortran Subject: Re: Quadruple-Precision Floating Point ? Summary: Expires: References: <8561@alice.UUCP> Sender: Reply-To: firth@bd.sei.cmu.edu (Robert Firth) Followup-To: Distribution: Organization: Carnegie-Mellon University, SEI, Pgh, Pa Keywords: REAL*16 hardware? obscure In article <8561@alice.UUCP> wcs@alice.UUCP (Bill Stewart, usually) writes: >Are there any machines that implement quad-precision (128-bit) floating >point numbers in hardware? Are there any commercial Fortran compilers >that support it? Yes to both. The DEC VAX-11 supports what they call 'H' floating point, which is 128 bits wide (16 bit exponent and 112 bit mantissa counting the hidden bit). The DEC Fortran compiler I believe supports all the VAX floating-point formats. Newsgroups: comp.lang.ada Subject: Re: Ada/UNIX(tm) and the NAME function Summary: Expires: References: <920005@hpcljws.HP.COM> Sender: Reply-To: firth@bd.sei.cmu.edu (Robert Firth) Followup-To: Distribution: Organization: Carnegie-Mellon University, SEI, Pgh, Pa Keywords: In article <920005@hpcljws.HP.COM> jws@hpcljws.HP.COM (John Stafford) writes: >Ada I/O has a function NAME which > > "Returns a string which uniquely identifies the external file > currently associated with the given file (and may thus be used in an > open operation). If an environment allows alternative specifications > of the name (for example, abbreviations), the string returned by the > function should correspond to a full specification of the name." > >So the question is, what should NAME do on a UNIX (tm) system? > > The first interpretation that comes to mind is that NAME should > return "a" fully rooted path to the given file. The term "a" is used > because with hard links there is no "the" fully rooted path to the > given file. Futher, on systems which support "alternative > specifications" like symbolic links or hidden files or alternative > file system universes, such should be "resolved" and made "explicit" > in the result. Things like references to . and .. (in the file > name given to the Ada I/O system by the user) are "alternative > specifications" as well and should be "resolved" and made "explicit" > in the result as well. The above seems a reasonable interpretation. Note that the Ada RM does not imply that there is only ONE string that uniquely identifies the file; it reqires only that the string be a "full" specification, ie one that does not depend on any hidden variables in the execution environment of the program (such as the current directory). >The problems with that interpretation are: > > 1. The name must be determined when the file is opened/created, > since the user may have specified a relative file name and may change > working directory after opening the file and before using NAME. I > recognize that changing working directory isn't directly supported by > Ada, but NAME should work even if the user does change working > directory since it is to return the "full specification of the name". I don't see this at all. It is necessary merely to "freeze" (by copy, presumably) any values in the environment on which the interpretation of the file might depend (eg the current working directory). It is not necessary actually to compute the name; that can be done later from the copied information. > 2. Even if the user gives a rooted path, the work still needs to be > done to resolve any "alternative specifications". > 3. The Ada I/O system ends up basically having to implement /bin/pwd > to walk up the directory tree to compute the fully rooted path. And > if it uses chdir(2) during the walk, it also needs to first determine > the current working directory so that it can "get back there" when it > is done resolving the path to the specified file. This potentially > has severe impact on the performance of all Ada open/create > operations. Surely the right answer is not to replicate this functionality in "Ada" (presumably the package body INPUT_OUTPUT is intended), but rather to add to your Unix system a routine that, when called with a "partial" file name and an environment, will return some appropriate "full" name. I fail to see why this process should be inefficient (though of course on Unix the most surprising things ARE inefficient). > 4. Lack of read or execute permission anywhere in "a" path to the > file in question (or to the current working directory in the chdir(2) > case) will cause this process to fail. Due to problem 1, it would > seem that the open/create must therefore fail (probably by raising > NAME_ERROR), even though the user may have permission to access the > file and will never need the NAME. An implementation that fails in this way is clearly erroneous. The appropriate course of action would be to look at alternatives. > 5. The error cannot be deferred to the actual use of NAME because > NAME is not defined as being able to raise any exception except > STATUS_ERROR and it may only do that if the file is not open. No: the fact that it is required to raise an exception does not imply (here or elsewhere) that it is forbidden to raise any otehr exception. Hope that helps a little. [idiot fodder - ignore] programs should do what they are told not what some bloody moron thinks would be a good idea and imposes on everyone else