cant compile program
in [Fortran]
|
Prev: fashion sunglasses wholesale from china,paypal payment and free shipping
Next: Fortran 77/90/95 free compiler
From: Richard Maine on 13 May 2010 14:21 Uno <merrilljensen(a)q.com> wrote: > I can't imagine the circumstance when a person would have to work around > a hollerith constant. I'm afraid would ascribe that mostly to a failure of imagination. I have certainly been involved in many such workarounds. It isn't particularly rare for code with Hollerith usage to show up in questions on this newsgroup. For something more concrete than the above allusions, consider the fact that most (perhaps even all, but I'll leave myself the out in case there is an exception that I've overlooked) current compilers support Hollerith. Such support is nontrivial; it doesn't come for free. Compilers wouldn't be supporting it if there were not circumstances where there was demand for it. In fact, IIRC, the initial release of NAG's f90 did not support Hollerith, but such support was added later due to user demand. Note that although Hollerith was not strictly standard f77, it was in an appendix of the f77 standard - what we would probably call an optional part of the standard today. Not until f90 was mention of it gone from the standard. Pretty much all f66 code that did anything with character data at all used Hollerith (there being little alternative). That code did not instantly get updated in the early 80's when f77 compilers became widely available. Programmers took longer to "update" than the codes. Many f66 programmers continued to use Hollerith out of habit for quite a long time after f77, and even f90 was released. I knew some of those programmers. Probably by now almost all of them have retired, though. Old Hollerith code needs work-arounds conversion of one wants to make it conform to the standard or if one wants to port it even in nonstandard form to a system with different word sizes than the original code assumed. Note also someone's correct comment that the code in question is not actually Hollerith. If it passed a compiler without cmplaint, that might be because the compiler accepted some Vax Hollerith extensions (to use quoted strings for Hollerith and to use Hollerith in assignments). I happen to dislike both of those extensions, partly because they do fail to catch errors like this. There are at least reasonable odds that this code never did use Hollerith. The rest of the code uses character data type and shows no evidence of Hollerith usage (it has H edit descriptors, which are related, but are not technically Hollerith). I'd say there was a chance that a character declaration got deleted along with the other uses of the variable, but that this line got mistaken;y left in. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 13 May 2010 14:57 Richard Maine <nospam(a)see.signature> wrote: > Uno <merrilljensen(a)q.com> wrote: >> I can't imagine the circumstance when a person would have to >> work around a hollerith constant. > I'm afraid would ascribe that mostly to a failure of imagination. > I have certainly been involved in many such workarounds. It isn't > particularly rare for code with Hollerith usage to show up in questions > on this newsgroup. > For something more concrete than the above allusions, consider the fact > that most (perhaps even all, but I'll leave myself the out in case there > is an exception that I've overlooked) current compilers support > Hollerith. Such support is nontrivial; it doesn't come for free. The H format descriptor supplies some almost ambiguous cases where a FORMAT statement can look like an assignment. Enough that WATFIV disallowed the string "FORMAT(" as the beginning of an assignment statement. (Slightly inconvenient as FORMAT is a convenient name for a variable format stored in an array.) Hollerith constants in DATA and CALL aren't so bad, though it can look funny if they have a comma in the value. > Compilers wouldn't be supporting it if there were not circumstances > where there was demand for it. In fact, IIRC, the initial release of > NAG's f90 did not support Hollerith, but such support was added later > due to user demand. And as I found out some time ago in this newsgroup, compiler support might not be enough. It seems to require support from the VAX/VMS linker. If you pass a hollerith (or appostrophed) string to a subroutine, Fortran 77 normally passes a descriptor. The VAX/VMS linker will convert the descriptor to a reference when it finds the target is not a CHARACTER variable. > Note that although Hollerith was not strictly standard f77, it was in an > appendix of the f77 standard - what we would probably call an optional > part of the standard today. Not until f90 was mention of it gone from > the standard. Pretty much all f66 code that did anything with character > data at all used Hollerith (there being little alternative). The MORTRAN2 processor reads in as the first record of the macro input file a record with all the characters that it uses, in A1 format. No Hollerith or apostrophed constants in the source. You can change the character code by changing that one record. (snip) > Note also someone's correct comment that the code in question is not > actually Hollerith. If it passed a compiler without cmplaint, that might > be because the compiler accepted some Vax Hollerith extensions (to use > quoted strings for Hollerith and to use Hollerith in assignments). I > happen to dislike both of those extensions, partly because they do fail > to catch errors like this. I like the quoted (or apostrophed) strings extension, as it avoids the problem of counting wrong when figuring out how long the string is. Well, more of a problem for H format descriptors. Otherwise, it was usual to initialize a variable in a DATA statement with a name similar to that of the constant, and use that everywhere the constant was needed. > There are at least reasonable odds that this > code never did use Hollerith. The rest of the code uses character data > type and shows no evidence of Hollerith usage (it has H edit > descriptors, which are related, but are not technically Hollerith). I'd > say there was a chance that a character declaration got deleted along > with the other uses of the variable, but that this line got mistaken;y > left in. Given the fact that the variable was REAL, that seems more likely. It was more usual to use INTEGER variables, especially as some machines would normalize on assignment, and may not be able to correctly compare as REAL. -- glen
From: Uno on 13 May 2010 23:44 Richard Maine wrote: > Uno <merrilljensen(a)q.com> wrote: > >> I can't imagine the circumstance when a person would have to work around >> a hollerith constant. > > I'm afraid would ascribe that mostly to a failure of imagination. > > I have certainly been involved in many such workarounds. It isn't > particularly rare for code with Hollerith usage to show up in questions > on this newsgroup. > > For something more concrete than the above allusions, consider the fact > that most (perhaps even all, but I'll leave myself the out in case there > is an exception that I've overlooked) current compilers support > Hollerith. Such support is nontrivial; it doesn't come for free. > Compilers wouldn't be supporting it if there were not circumstances > where there was demand for it. In fact, IIRC, the initial release of > NAG's f90 did not support Hollerith, but such support was added later > due to user demand. > > Note that although Hollerith was not strictly standard f77, it was in an > appendix of the f77 standard - what we would probably call an optional > part of the standard today. Not until f90 was mention of it gone from > the standard. Pretty much all f66 code that did anything with character > data at all used Hollerith (there being little alternative). That code > did not instantly get updated in the early 80's when f77 compilers > became widely available. Programmers took longer to "update" than the > codes. Many f66 programmers continued to use Hollerith out of habit for > quite a long time after f77, and even f90 was released. I knew some of > those programmers. Probably by now almost all of them have retired, > though. > > Old Hollerith code needs work-arounds conversion of one wants to make it > conform to the standard or if one wants to port it even in nonstandard > form to a system with different word sizes than the original code > assumed. > > Note also someone's correct comment that the code in question is not > actually Hollerith. If it passed a compiler without cmplaint, that might > be because the compiler accepted some Vax Hollerith extensions (to use > quoted strings for Hollerith and to use Hollerith in assignments). I > happen to dislike both of those extensions, partly because they do fail > to catch errors like this. There are at least reasonable odds that this > code never did use Hollerith. The rest of the code uses character data > type and shows no evidence of Hollerith usage (it has H edit > descriptors, which are related, but are not technically Hollerith). I'd > say there was a chance that a character declaration got deleted along > with the other uses of the variable, but that this line got mistaken;y > left in. > My imagination is just fine, Richard; I have no experience with Hollerith constants, as my fortran instruction began much later than Glen's, for example. I wouldn't mind learning more about them, and so we turn to the wiki: In this program, nothing is declared explicitly, so how can you know what is a hollerith constant and what isn't? C PROGRAM HELLO1 C INTEGER IHWSTR(3) DATA IHWSTR/4HHELL,4HO WO, 3HRLD/ C WRITE (6,100) IHWSTR STOP 100 FORMAT (3A4) END Your example from nag could work both ways. f90 is modern by some measures, but it is also definitely two decades ago. Computer generations are less than dog generations, so that's two generations ago minimum. I guess Tobias thought that OP's source had a hollerith constant and I responded as if that were indeed the case. Tobias is no lightweight, so it might be something that is well worth knowing. -- Uno
From: fj on 14 May 2010 00:43 On 14 mai, 05:44, Uno <merrilljen...(a)q.com> wrote: > Richard Maine wrote: > > Uno <merrilljen...(a)q.com> wrote: > > >> I can't imagine the circumstance when a person would have to work around > >> a hollerith constant. > > > I'm afraid would ascribe that mostly to a failure of imagination. > > > I have certainly been involved in many such workarounds. It isn't > > particularly rare for code with Hollerith usage to show up in questions > > on this newsgroup. > > > For something more concrete than the above allusions, consider the fact > > that most (perhaps even all, but I'll leave myself the out in case there > > is an exception that I've overlooked) current compilers support > > Hollerith. Such support is nontrivial; it doesn't come for free. > > Compilers wouldn't be supporting it if there were not circumstances > > where there was demand for it. In fact, IIRC, the initial release of > > NAG's f90 did not support Hollerith, but such support was added later > > due to user demand. > > > Note that although Hollerith was not strictly standard f77, it was in an > > appendix of the f77 standard - what we would probably call an optional > > part of the standard today. Not until f90 was mention of it gone from > > the standard. Pretty much all f66 code that did anything with character > > data at all used Hollerith (there being little alternative). That code > > did not instantly get updated in the early 80's when f77 compilers > > became widely available. Programmers took longer to "update" than the > > codes. Many f66 programmers continued to use Hollerith out of habit for > > quite a long time after f77, and even f90 was released. I knew some of > > those programmers. Probably by now almost all of them have retired, > > though. > > > Old Hollerith code needs work-arounds conversion of one wants to make it > > conform to the standard or if one wants to port it even in nonstandard > > form to a system with different word sizes than the original code > > assumed. > > > Note also someone's correct comment that the code in question is not > > actually Hollerith. If it passed a compiler without cmplaint, that might > > be because the compiler accepted some Vax Hollerith extensions (to use > > quoted strings for Hollerith and to use Hollerith in assignments). I > > happen to dislike both of those extensions, partly because they do fail > > to catch errors like this. There are at least reasonable odds that this > > code never did use Hollerith. The rest of the code uses character data > > type and shows no evidence of Hollerith usage (it has H edit > > descriptors, which are related, but are not technically Hollerith). I'd > > say there was a chance that a character declaration got deleted along > > with the other uses of the variable, but that this line got mistaken;y > > left in. > > My imagination is just fine, Richard; I have no experience with > Hollerith constants, as my fortran instruction began much later than > Glen's, for example. I wouldn't mind learning more about them, and so > we turn to the wiki: > > In this program, nothing is declared explicitly, so how can you know > what is a hollerith constant and what isn't? > > C PROGRAM HELLO1 > C > INTEGER IHWSTR(3) > DATA IHWSTR/4HHELL,4HO WO, 3HRLD/ > C > WRITE (6,100) IHWSTR > STOP > 100 FORMAT (3A4) > END The Hollerith constant is in the DATA statement : 4HHELL for instance, the first H for Hollerith, the digit 4 meaning the 4 characters after the first H. Such constant was (is ?) also often used in formats. Here, the first value of IHWSTR contains the string 'HELL' (4HHELL = 'HELL'). In addition, the program HELLO1 is a typical FORTRAN-66 programming when CHARACTER variables did not exist yet : an integer array is used to contains characters (4 characters by integer). > > Your example from nag could work both ways. f90 is modern by some > measures, but it is also definitely two decades ago. Computer > generations are less than dog generations, so that's two generations ago > minimum. > > I guess Tobias thought that OP's source had a hollerith constant and I > responded as if that were indeed the case. Tobias is no lightweight, so > it might be something that is well worth knowing. > -- > Uno
From: Louis Krupp on 14 May 2010 06:07
On 5/13/2010 9:44 PM, Uno wrote: > Richard Maine wrote: >> Uno <merrilljensen(a)q.com> wrote: >> >>> I can't imagine the circumstance when a person would have to work around >>> a hollerith constant. >> >> I'm afraid would ascribe that mostly to a failure of imagination. <snip> > My imagination is just fine, Richard ... <snip> Perhaps imagination is the wrong word; how about "life experience"? Can you conceive of: Black & white TV? Postal zones instead of zip codes? Party lines (hint: they're not something you snort)? Rotary telephones? Punched cards? Radios with vacuum tubes instead of transistors? Twenty shillings to a pound, and twelve pence to a shilling? Hollerith constants will be on that list some day. Louis |