forums.silverfrost.com

wahorger · Joined: 13 Oct 2014 Posts: 1225 Location: Morrison, CO, USA

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.

PaulLaidler · Posted: Tue Oct 02, 2018 7:28 am Post subject:

Thanks for the feedback.

LitusSaxonicum · Posted: Tue Oct 02, 2018 11:14 am Post subject:

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:

LitusSaxonicum · Posted: Tue Oct 02, 2018 12:26 pm Post subject:

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):

wahorger · Joined: 13 Oct 2014 Posts: 1225 Location: Morrison, CO, USA

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.

LitusSaxonicum · Posted: Wed Oct 03, 2018 10:49 am Post subject:

... 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 ...

wahorger · Joined: 13 Oct 2014 Posts: 1225 Location: Morrison, CO, USA

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]