Question about Hollerith formatting

[Richard E Maine]

On Sep 13, 2005, at 2:23 AM, Feng Wang wrote:

> But obviously, elements of
> character array should be allowed. So from this point, to keep 
> consistency, we
> allow elements of other type is also logical.

No, elements of a character array are not allowed... not as a 
Hollerith. By definition, Hollerith involves having character data in a 
non-character data object. If it is a character type, then it isn't 
Hollerith. You can use a character array element as a format, but 
that's because you can use a general character expression, of which a 
character array element is a trivial case.

Hollerith usage is not at all like anything else. You will not be able 
to draw "logical" conclusions about it. I'm afraid that if you try, you 
will run into inherent contradictions, inconsistencies, and conflicts. 
It isn't "logical" to use non-character data types for character data. 
The syntax for doing so is full of special-case syntax and hacks.

For example, if you think that you should follow the same "logic" as 
used for character expressions, then I guess you need to allow 
completely general expressions, just like in the character case. The 
only limitations in the character case are that the type has to end up 
character, the value has to form a valid format, and you have to obey 
the usual restrictions on things like side effects. If you want to 
"logically" extrapolate that to Hollerith, then 123.4+567.8 would be a 
valid Hollerith format as long as it happened to have the right bits to 
form a valid format (it probably doesn't).

I repeat and reemphasize my recommendation to stick with what the 
standard said on this, supplemented only if absolutely necessary by 
other existing practice. I think that you should *NOT* be trying to 
redesign this feature based on some notion of "logic". Doing that will 
result in spending a lot of time redoing what people have done before. 
People did think through these things in making the f77 standard. Some 
of them were pretty smart people. I don't always agree with every 
decision they made (or anyone else; sometimes I disagree with my own 
decisions in retrospect). But you need to at least respect that they 
put considerable thought into the matter - far more than anyone on this 
thread has done or is prepared to do. Anyway, no matter how hard you 
try, you aren't going to get a result on this that is "logical". I 
absolutely guarantee it will have inconsistencies. Plus you'll have a 
good chance of breaking other things (such as statement label 
assignment).

The standard isn't gospel. There are times to go outside of it. But it 
is the place to look first, and you should have darned good reasons for 
doing something different in an area that the standard covers. This 
*IS* an area that the standard covers (or anyway, the old standard 
did).

If a user has code that depends on things like using array elements for 
Hollerith, then that code is already nonportable, has been for a long 
time, and should just be fixed. It is darned unlikely that there are 
huge volumes of code like that, because there are too many compilers 
that it won't work on (like most compilers).

-- 
Richard Maine                |  Good judgment comes from experience;
Richard.Maine@nasa.gov       |  experience comes from bad judgment.
                             |        -- Mark Twain