Re: COMMON structures and text parsing

In article <1irivoe.1sjjsm01mi0txwN%nospam@xxxxxxxxxxxxx>,
nospam@xxxxxxxxxxxxx (Richard Maine) wrote:

Ron Shepard <ron-shepard@xxxxxxxxxxxxxxxxxx> wrote:

In article <ghdimf$ok4$1@xxxxxxxxxxxxxxxxxxxxxxxx>, nmm1@xxxxxxxxx
wrote:

Fortran does this better, and always has done. It is a slight extra
complication to have a proper separate type, but makes everything just
SO much cleaner.

The place where this choice is not "cleaner" is when you need to
index into an array using a logical value.

which is not essentially different from indexing an array using any
other type.

This is true. But we are talking about strings of bits in any case,
and strings of bits can always be interpreted to have an integer
value (in the mathematical sense, although not necessarily a fortran
INTEGER).

Sorry, but I like the compiler catching errors such as using
incorrect types for things like that.

That is exactly my complaint. The way things are now, you have to
work against the compiler. I want the compiler to work with me to
solve the problems.

Any trivial syntactic
inconvenience for the cases where one might imagine want to do things
like that is dwarfed by the improved reliability from having the
compiler diagnose the erroneous cases - at least in my opinion.

I guess we disagree. I thought my example was clear enough to
demonstrate my point about "clean" code.

Not to speak of the fact that I find the whole business of interpreting
a logical as an integer confusing. In your example, that translates into
me being uncertain which value is first in the array.

I think this could be done in such a way that the order is
irrelevant. You can *almost* achieve that goal when you roll your
own code using integers as shadow logicals, so I think the language
syntax could be defined in such a way to fully achieve that goal.

value(.true.) = whatever
value(.false) = whatever_else
...
x = value(logical)

I guess I did not say this before, but the compiler should complain
if I try to index the value(:) array with anything other than a
logical value. This is what I meant when I said that the compiler
should help you maintain the code. Currently when you do this, with
fortran integers mimicking the logical values, you do not get this
kind of help from the compiler.

When I write C code, I'm always having to go check the definition or I
get it wrong a significant fraction of the time.

I have the same problem with C code. That's not what I want for
fortran. I don't want to have

int = .true.

or

logical = int

or anything like that. I want to cleanly index into an array with
logical values (and only logical values for such arrays).

If you really want to do that, Glen showed a solution to your sample
code using the merge intrinsic. I'd say his was a very clean solution,
as that is exactly what the merge intrinsic is; this isn't some arcane
special case of it. Or you could write your own short function to do
whatever you want with any particular type.

Yes, the use of functions is another way to achieve this goal.
However, when all you really need, or want, is an array lookup, a
function is a roundabout way of getting it. I already commented on
the merge() intrinsic. IMO, that still is not as clean as a simple
array reference in those cases where a simple array reference is all
you really want.

Seems to me as though you are looking for something like associative
arrays (I think that's the term), where you can "index" an array with
darn near anything.

Yes. My need for these has always been with logical values, but
there would be nothing wrong with allowing arrays to be indexed with
other data types with similarly limited values. I'm not so fond of
allowing, for example, arrays indexed by arbitrary character
strings, as in perl. I think these are called "hashes" or also
"associative arrays". This is another example of how arrays can be
used without the programmer knowing the order of the stored elements.

In particular, if the array index is going to be
some type other than integer, you really have that type be the index
instead of somehow faking that type to be interpreted as an integer for
this purpose.

I think we agree on this point. We differ in our terminology
because ultimately any array index, no matter how the bits are
stored, must be interpreted as an integer offset.

If you
do an associative array of logicals and do it "right", then the question
of which logical value is "first" doesn't come up to confuse people like
me.

As I showed above, you can almost achieve this now with integers
treated as shadow logical values, so I think the compiler should be
able to fully achieve this.

IMO, things really would have been simpler for fortran to have just
defined integer values for .true. and .false. 40 years ago. Then
neither fortran nor C would be in the situation they are now.

I might say instead that I'm impresed at the foresight shown by
avoiding that and thus keeping the door open for associative arrays to
be done "properly" some day.

I don't really know about 40 years ago, that was before my time as a
programmer, but by the time f77 was approved this could have been
done the right way. And certainly by the time f90 was approved it
could have been done.

Of course, I'm sure there was no such
explicit intention, but I think that a "clean" underlying structure that
avoids conflating the concepts of integers and logicals just naturally
makes for a better base even for things that one hasn't explicitly
thought of yet.

But the current situation requires the programmer to conflate the
concepts of integers and logicals. That is exactly what I am
complaining about.

$.02 -Ron Shepard
.

Relevant Pages

  • Re: COMMON structures and text parsing
    ... The place where this choice is not "cleaner" is when you need to ... index into an array using a logical value. ... Logicals do not. ... do an associative array of logicals and do it "right", ...
    (comp.lang.fortran)
  • Re: sumif column contains text
    ... This expression will return an array of either TRUE or FALSE: ... SUMPRODUCT calculates numbers so we have to convert those logicals to ... circle, red circle, yellow circle, blue square, red square and so ...
    (microsoft.public.excel.misc)
  • Re: sumif column contains text
    ... Valko" wrote: ... This expression will return an array of either TRUE or FALSE: ... SUMPRODUCT calculates numbers so we have to convert those logicals to ... circle, red circle, yellow circle, blue square, red square and so ...
    (microsoft.public.excel.misc)
  • Re: one-liner for characater replacement
    ... Bit strings and LOGICAL arrays? ... It looks like an array ... likely only serve to allow reverse engineering to LOGICALs ... but only for comparison purposes. ...
    (comp.lang.fortran)
  • Re: Idea for ECMA/C# Standard - compile time hash for performance
    ... I agree with you the chance of a compiler change is slim, ... and then delegating to the standard hash for fields accessed less frequently. ... or the array lookup which would require the ... > 64-bit architecture) for each enum value that doesn't map to anything. ...
    (microsoft.public.dotnet.languages.csharp)