Booleans in BASIC

[Tony Gravagno]

On Sunday, May 10, 2015 at 8:17:47 PM UTC-7, Peter McMurray wrote:

TG mentioned binary compares such as IF X THEN ... I developed a hatred of that because what was regarded as true or false varied from system to system. In fact it probably still does some require a precise 0 or 1 others regard 0 as false and anything else true until one hits the dreaded null - null because it was set or null because it was never initialised. In fact Turing defined zero as true.

Regarding Boolean tests : IF X THEN or IF NOT(X) THEN or IF X ELSE ...
I thought this was worth a thread of its own...

Peter presents two arguments against Booleans (not binary compares) which I'd like to refute:

1) The argument that the values of True and False are not standard.
I'm not sure how true that is. If I use 0 for false and 1 for true, can anyone cite a MV platform where those aren't interpreted as expected?

And if you suspect your code is going to be ported to another platform then it's easy to code for it:

TRUE = (1=1)  ;  FALSE = NOT(TRUE)

Then:    Flag = TRUE

With just that simple setup the entire problem of 0 and 1 is avoided. Some MV platforms already have @TRUE and @FALSE. Ironically, that elegant solution is as unportable as the 0 or 1 option. But using the above technique it's trivial to swap that one first line and all the rest of the code works exactly the same:

TRUE = @TRUE  ;  FALSE = @FALSE

So enough with the hatred of syntax. What's wrong with that?

OK, if someone sets variables to 0 and 1 in code, there may be a chance that the code is not portable, assuming on some platform these values are not False and True, respectively. Well, I do this in all of my code, and my products do run on all MV platforms. However, if someone can prove that 0 is not false and 1 is not true on some platform, I'll commit now to never using 0 and 1 again, and from now on I'll use the 1=1 technique above.

2) The argument that somehow the value of a Boolean can be accidentally set to some other value.
Really now, this could happen with any variable. If we can't trust that any given variable is going to be used properly then we can just hang up this whole business. If a developer is going to use a flag with 0 or 1 then chances are very slim that the same developer is going to somehow assign another value. Duh, that will break the code. And if someone else breaks the code, well, stop breaking the code! That whole argument is as invalid as "what happens if someone resets the YTD value to zero?" or "what happens if someone nulls out the customer name?" These things don't happen in real life except through incompetence, and if you have incompetent people messing up your code, your problem isn't coding style.

So, I personally don't see a valid argument against using Booleans, except as a matter of personal style. Thoughts?

Thanks,
T

[Martin Phillips]

The important point here is that the multivalue Basic language defines that anything that returns true or false returns one and zero respectively and further broadens the definition to say that using a value as a Boolean treats zero and a null string as false, everything else as true (let’s leave the SQL style null out of this for now). There is no room for disagreement. This is how the language says it works. Yes, other languages may define true/false differently (VB uses -1 for true) but they define lots of other differences too and we accept that.

 

Of course, complications can arise. When we did the data collections development for QM, we needed to be able to parse a JSON string into a collection and then rebuild it later. JSON defines a Boolean data type and it would be totally unacceptable for true/false to be translated to 1/0 in Basic only to end up as numeric values if we rebuild the JSON representation. To get around this, we implemented an internal Boolean data type but, for compatibility with the way the language definition says things must work, this is completely interchangeable with the numeric style in program expressions. Just about the only place this is visible is in the debugger where the data type may appear as Boolean.

 

Booleans are fine (my opinion and feel free to disagree). On the other hand, I have a strong hate of

   IF X ELSE ….

instead of

   IF NOT(X) THEN …..

 

I suspect that the language only supports this because the THEN/ELSE clause attaches to so many other statements such as

   READ VAR FROM FVAR, ID ELSE …

 

Ultimately this is just a matter of style and, possibly, coding standards. If someone who has never seen the program before can understand what it is doing, that sounds good to me.

 

 

Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England
+44 (0)1604-709200

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[Wols Lists]

On 11/05/15 20:17, Martin Phillips wrote:
> Booleans are fine (my opinion and feel free to disagree). On the other
> hand, I have a strong hate of
>
> IF X ELSE ….
>
> instead of
>
> IF NOT(X) THEN …..
>
>
>

While I'd much rather, if X is an expression, have it "easy to understand".

IF EVERYTHING EQ OKAY ELSE ...

is fine by me. Okay, in this example, changing it to

IF EVERYTHING NE OKAY THEN

works fine too, but I've hit plenty of examples where it doesn't. And
no, I don't consider sticking "NOT" round a complex expression a "minor"
change.

I agree in that I prefer to use a THEN, but if an ELSE makes sense, I'd
rather use that than a NOT.

Cheers,
Wol

[Tony Gravagno]

>
On Monday, May 11, 2015 at 12:17:29 PM UTC-7, Martin Phillips wrote:

The important point here is that the multivalue Basic language defines that anything that returns true or false returns one and zero respectively and further broadens the definition to say that using a value as a Boolean treats zero and a null string as false, everything else as true (let’s leave the SQL style null out of this for now). There is no room for disagreement. This is how the language says it works. Yes, other languages may define true/false differently (VB uses -1 for true) but they define lots of other differences too and we accept that.

>

 

Thanks for your comments, Martin. That's confirmation to refute the common argument of "what happens if 1 isn't true on some platform". I've seen people say "what if the value is -1 or null?". Well, don't set it to a value other than 0 or 1 and you won't need to worry about it! They also say "-1 is true in other platforms". OK, but this isn't another platform!


 >

Booleans are fine (my opinion and feel free to disagree). On the other hand, I have a strong hate of

   IF X ELSE ….

instead of

   IF NOT(X) THEN …..

>


 
Just to clarify, I also have an aversion to IF X ELSE, but I'd rather not complicate the discussion of Booleans with this specific nuance. When checking for a false condition I'll sometimes do this:

IF DONE THEN
* nothing to do here ... explicit, easy to read, easy to fill in later if required
END ELSE
  ... functional code ...
END

But I'm hoping those who have an aversion to Booleans in general will focus on the higher level question of whether or not these flags really are evil.

If we're talking about personal preferences, that's fine. But what I'm wondering is, are people basing a preference on misinformation? Or are they rationalizing a preference just to say there's a reason for it? We don't need to have a reason for preferences - but when there is no reason I don't think misinformation should be perpetuated as this one seems to be.

Best,
T

[Peter McMurray]

Hi

I agree with Wol clarity is paramount. Setting a value of TRUE or FALSE I am perfectly happy with. However it is the ludicrous examples that Martin gave such as IF (complex expression) ELSE that give me the irrits.

The use of NOT is a pedantic confusion in some areas. I remember my extreme annoyance at having to go through hundreds of ENGLISH statements to switch the position of NOT to after the dictionary name and having to explain this pedantic change to users that understood and used ENGLISH statements. All because some  pedant decided to change the Pick standard in Open Architecture.

As they say in the States YMMV.

[Peter McMurray]

Hi again

It appears that TG's response and mine overlapped. I am afraid I have to disagree. Whilst the statement about zero, 1 and null may well have been true for some platforms it definitely was not for all platforms. One remembers that there were over 150 licensees ranging through machines such as Wicat, DEC farms running Unidata,  Prime, EDGE running Open Architecture etc.. I have hit every one of the examples that I gave. In fact the confusion can be seen in the documentation.

PC AT specifically states that any result must be numeric and that zero is false. By the time of advanced Pick that has changed to " if the expression evaluates to any non-zero value, zero is returned" . One can easily see this being interpreted differently on other platforms.

In fact TG's excellent example of clarity is pooh-poohed by the ePick manual writer

IF DONE THEN
* nothing to do here ... explicit, easy to read, easy to fill in later if required
END ELSE
  ... functional code ...
END

Obviously the appropriate command at " nothing to do here" is NULL however this is described in ePick as

" Typically used ( by confused programmers) in a single line if construction as in the following example

if on.file then null else...

which could alternately be coded as

if on.file else "

Also I checked on the NOT statement in ENGLISH and the OA stuff up appears to have been fixed up later on. Of course this is rather like telling the person lying in hospital because there car ignition turned off mid highway that it will all be ok in the next model :-(
 

[Tony Gravagno]

Can you or anyone provide a single example of how a current MV platform does not treat zero as false and one as true?

Please do not include references to OA, PC AT, other dead platforms, or erroneous doc notes from a couple decades ago. Let's focus on what's here and now.

Once again you follow a pattern of adding something that I never said and then you proceed to correct it. Regarding:

IF DONE THEN
* do nothing
END ELSE * do something

I didn't use the NULL keyword. It's not even necessary, it's implied. But the placeholder leaves room for growth and the code is easily readable. The old EPick comment goes on to suggest a syntax that you and others here eschew - as do I, so I didn't suggest it here. So again, please don't correct something that I didn't say in the first place.

We have at least three ways to express that concept, the above plus IF NOT(flag) plus IF flag NE TRUE. It doesn't matter how one approaches testing a condition. Syntax is trivial. Every programming language includes the concept of Boolean tests and this is used extensively and unavoidably elsewhere. My question is about whether there are any technical reasons why some Pick people adverse to this.

RE: "if the expression evaluates to any non-zero value, zero is returned"
You have mis-read that snippet. In context it comes from the NOT() function, where yes, anything that is not zero is true, so anything that is NOT(true) is false or zero. That is entirely consistent, though confusing out of context.

And since from the very first post I said that usage of Boolean flags is limited to 0 and 1, there is no such thing as an expression which confusingly evaluates to anything but 0 or 1.

So limiting your discussion to valid code on a current platform, do you have any reservations which can be technically substantiated outside of a perfectly valid "I prefer not to do that"?

And did you really get a client to completely change their query syntax based on a documentation typo? Ouch.

T

[Kevin Powick]

I guess this conversation is going on in another thread as well, but I'll answer here only.

Boolean comparisons using True/False (1/0) are great and I use them all the time.  On current MV systems, I believe they all interpret 0 as False.

For my bit on the "style" debate. 

The following is my typical and preferred style.

IF DAYTIME THEN

   OPEN.CURTAINS

END ELSE

   CLOSE.CURTAINS

END

The following is also just fine. Like my preferred style it reads like humans think.

IF NOT(DAYTIME)THEN

   CLOSE.CURTAINS

END ELSE

   OPEN.CURTAINS

END

The following looks like a hack to me, and I would never use it.

IF DAYTIME ELSE

   CLOSE.CURTAINS

END

ELSE implies some other action was possible, but that's not the case in the above format.  The implied THEN is "do nothing", but I prefer code that is explicit.  IF this THEN action(s) ELSE other.action(s).

--

Kevin Powick 

[Peter McMurray]

Oh Dear TG I did say that your example was good and the manual was not.

No I did not get a client to change based on a typo. I had to change my code and retrain the client because OPEN ARCHITECTURE WAS A MESS and my statement regarding the use of NOT in ENGLISH/ACCESS at that time is correct. That of course was relatively minor compared to the cretin who decided that the appropriate response to a tape read error was system halt>memory dump on a major installation with several offices.

My objection to BOOLEAN still stands unless it is used with the clarity of both your example and Kevin's.

Best you stop speed reading and taking umbrage where there was no criticism mate.

[Peter McMurray]

TG said

Can you or anyone provide a single example of how a current MV platform does not treat zero as false and one as true?

I shall allow the current D3 manual the last word on this please note the statement "This tends to vary somewhat between implementations" I rest my case use it and get burned avoid and all will be well

Boolean Evaluation

Traditionally, the result of a logical or Boolean expression is considered true if it evaluates to 1 and false if it evaluates to 0.

In the D3 system, expressions that depend on a result of true or false also evaluate other values as true or false. This tends to vary somewhat between implementations. In generic D3, any nonzero integer that is positive or negative, evaluates to true. For example:

x = 5 if x then stop

Because x is a nonzero integer, the program takes the then branch and stops. In generic D3, any zero or null value evaluates to false. For instance:

y = "" if y then stop else print "yup"

This prints yup because y is evaluated as false. Some D3 implementations additionally evaluate any negative numbers as false, and positive numbers as true. This also holds true for +, -, ., +., and -..

This means that you must test your system to determine how it handles true and false. This program does it:

loop print "value to test " : input value until value = "quit" do if value then print "true" else print "false" repeat

Test it with negative numbers, null (Enter), positive numbers, letters, and so on.

A relational expression evaluates to 1 if the relation is true, and evaluates to 0 if the relation is false.

[Tony Gravagno]

Well, here's another fine thread gone down the rabbit hole.

My conclusions as I attempt to retire this thread:

- Booleans in BASIC are fine, just not used much by people who only use MV BASIC. For their usefulness, and yes clarity, I will continue to use them, though I'll try to adopt the technique of assigning TRUE=(1=1);FALSE=NOT(TRUE) and then using Flag=True rather than Flag=1. (That said I wrote some code today with a devilish grin:  DONE=LINES>=TOTAL.LINES, of course to be used later with UNTIL DONE.)

- It seems to be an unsupportable rumor that in BASIC 0 and 1 are not universally false and true, respectively. The syntax above should work on any system running today.

- In this thread I've not seen a single valid argument against this concept, outside of personal preference for whatever reason - which I actually do consider to be valid as long as it's not disguised as something technical.

- If we stick to IF Flag THEN, the code is considered readable. IF NOT(Flag) THEN (common in other languages as if !Flag)  is preferable to IF Flag ELSE (not even available in most other languages), but IF Flag THEN DoNothing ELSE DoSomething might be as welcome.

And about Locate (at least in D3), see the ARS, DRS sorting option for numerics.

I thank everyone once again for participating.

T

[Brian Speirs]

Hi Peter,

While your quoted text does indicate that there is ambiguity in relation to assessing whether an arbitrary value evaluates to TRUE or FALSE, that isn't actually a reason to not use booleans.

I think it it is important to distinguish between use of defined boolean values (either @TRUE/@FALSE, or EQUATE TRUE TO 1; EQUATE FALSE TO 0), and implied boolean values. For example:

CRT "Enter 1 to continue, or 0 to stop: "
INPUT X
IF NOT(X) THEN STOP

Given that most non-zero, non-null values will evaluate to TRUE (although I was interested to see that D3 might consider negative values to be FALSE), the above code fragment will not work as expected.

But that is bad programming, rather than boolean values being bad.

Personally, I use boolean values all the time, and I think they are an important part of any computer language. Fortunately, we have choice in how we program, and you don't have to use them directly. But, you are always using them in an indirect fashion, for if we put a better test on the above code fragment, such as:

IF (X NE 1) THEN STOP

then the (X NE 1) fragment evaluates to a boolean. So you could use:

Y = (X NE 1)
IF Y THEN STOP

Whether you like it or not, you can't get away from them!

Cheers,

Brian

[Tony Gravagno]

Peter, thank you for looking that up. Unfortunately that text comes from EPick, circa 1990, and it's readily found in AP/Ref through 1995. I would not be surprised at all if Jon Sisk says those were his words from the Pick Pocket Guide from 1982. At the time when that text was written it was probably true. With the coming of D3, most of the references to "PICK" in that book were simply (unfortunately) mass-replaced to "D3". As an example, there is no such thing as "generic D3" - that text used to say "generic PICK" with a reference to R83 licensees.

On a knee-jerk I might have sent a reference to that page to Rocket for review/correction, but I've already done that once this week and occupied more of their time than I feel was due. So for myself I'll resolve this documentation point as invalid.

Thanks.
T

 Peter McMurray wrote:

I shall allow the current D3 manual the last word on this please note the statement "This tends to vary somewhat between implementations" I rest my case use it and get burned avoid and all will be well "...In the D3 system, expressions that depend on a result of true or false also evaluate other values as true or false. This tends to vary somewhat between implementations. In generic D3, any nonzero integer that is positive or negative, evaluates to true."

[Peter McMurray]

Actually ePick came out in October 1992. However the place where a person learns Pick is the manual or bitter experience - such as the change in NOT usage in ENGLISH/ACCESS where programs that worked well for years suddenly fell over and unreliable implementations of Boolean commands..

 

The fact that this topic has caused such confusion, as evidenced in another thread and here, is surely evidence enough that constructs such as IF NOT(x) ELSE ...should be totally avoided and even ones with apparent clarity such as IF DAYLIGHT... should be used with extreme care, particularly when programmers with other backgrounds where the rules are different are involved.

As I said in the first place YMMV 

[Jan Van Schalkwyk]

I tried to pass a Boolean once - it was really painful. Then I took a conditional, and I felt much better.

[Dawn Wolthuis]

I wish I knew whether that statement was true or false, Jan. At this point I'm going to have to tag it as unknown.

FWIW, count me as pro boolean (and anti-three-valued-logic, should we go there next?).   --dawn

On Thu, May 14, 2015 at 5:56 PM, Jan Van Schalkwyk <midi...@gmail.com> wrote:

I tried to pass a Boolean once - it was really painful. Then I took a conditional, and I felt much better.

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

--

Dawn M. Wolthuis

Take and give some delight today