WINIO@ using LOGICAL as well

For the next compiler update?

There are many winio@ functions that could use a LOGICAL to control selection and/or enable rather than INTEGER. A LOGICAL for a radio button/checkbox makes more sense as well.

Being able to use either INTEGER or LOGICAL would be useful in (1) using existing code without problem and (2) making the code more readable.

Thanks for the feedback.

Since LOGICAL is .TRUE. or .FALSE. it can only be represented by 2 out of the very many bit patterns available in a variable of 1 or more bytes in length. In FTN95, these coincide with 0 (F) and 1 (T). If you look at an icon for ON/OFF on just about any electric item, it is represented by a combination of 0 and 1. If you are inventive in your programming, you can use LOGICAL tests on the 0 and 1, and guarantee that your source code is ureadable in the future, even though it works just fine!

Actually, you don't need to be very inventive, just use EQUIVALENCE. As in this:

      PROGRAM CONTORT
      LOGICAL*4 ISITTRUE
      INTEGER*4 ISITINTEGER
      EQUIVALENCE (ISITTRUE, ISITINTEGER)
      ISITINTEGER = 1
      WRITE (*,*) ISITTRUE, ISITINTEGER
      ISITINTEGER = 0
      WRITE (*,*) ISITTRUE, ISITINTEGER
      END

As I have noted on many occasions, a variable type called POLITICAL could be invented to use all the bit patterns. POLITICAL*4, for instance, could contain a spectrum of over 4 billion values, only one of which is completely true - and of course, only one is completely false.

Eddie

And as a Postscript to the above, sometimes the LOGICAL seems topsy-turvy. Take for example, this (extracted from FTN95.CHM about the %bt button format code):

grey_ctrl is set to 1 to enable the button and 0 to disable (grey) it.

e.g. TRUE to enable the button, not TRUE to grey it out. It's better to think of the code as 'Activate the button' (or 'Is it Enabled?' rather than 'Is it greyed?')

Eddie

Eddie,

Part of what you describe is a pathological case; that is: using an integer to represent a variety of 'truths'.

The way FTN95 works for logicals (I have used the equivalence in my own code) is a zero is FALSE and anything else is TRUE. So a LOGICAL only has two possible outcomes, in response to the underlying value.

All that aside, your code example illustrates bad code IF there is another alternative. If I need a logical (ISITRUE) yet read it from the file as ISITINTEGER, I have just left myself a rabbit hole down which to travel when using these variables 10+ years from now.

I'd like to have a logical alternative (pun intended), and use that.

... or a variety of untruths. Don't ever go into politics if you believe in absolutes. It wasn't a serious suggestion, by the way.

There's no such thing as an INTEGER, LOGICAL, or REAL (etc) - only bit patterns. Anyway, you started the Alice stuff (but through the Looking Glass rather than down the Rabbit Hole), so:

'When I use a word,' Humpty Dumpty said in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less.' 'The question is,' said Alice, 'whether you can make words mean so many different things.' 'The question is,' said Humpty Dumpty, 'which is to be master— that's all.'

The proper answer to Alice is 'Yes, you can.'

I have the benefit of near-certainty that in 10 years time I won't be being bothered by any Fortran coding style, good or bad. Oddly, this was not the case nearly a half century ago when I started with Fortran IV (subset). I can still read the stuff and make sense of it - which is more than I can of the newfangled stuff ...

I have been able to, st least temporarily, come up with a way to use logicals directly in the winio@() call. Clunky, but it works.

It uses both the CORE and LOC functions, such that the following syntax gets the results I'm looking for.

If one takes CORE4(LOC(LOGICAL)), this is interpreted as supplying an INTEGER*4 argument in a winio@() call.

The code is still readable, but still a bit obtuse. That said, the syntax of the fix is certainly a marker for 'something odd is going on here', so can't be ignored when prforming maintenance years in the future. [/code]