Boolean Statements

[Charles Pegge]

These are useful for collecting state information for later action, or for breaking down complex logic into simpler expressions.

Code: [Select]

'BOOLEAN STATEMENTS
sys a
a = (1.0+1.0==2.0) '-1
a = (1.0+1.0>=2.0) '-1
print a
a = (1.0+1.0>2.0)  '0
a = (1.0+1.0<>2.0) '0
print a
a = ("Hello"=="Hello") '-1
a = ("Hello"=="hello") '0
a = ("Hello"<>"hello") '-1
print a


[Peter]

very simple, but confusing for Aurel! 

[Peter]

Code: [Select]

sys a
iF a=1.0+1.0 = 2.0
   print "TRUE"
End iF   

iF a=1.0+1.0 >= 2.0
   print "TRUE"
End iF   

iF (a=2.0) > 2.0 
   print "FALSE"
End iF

iF (a=2.0) <> 2.0 
   print "FALSE"
End iF

iF (a=2.0) < 2.0  'does not work 
   print "FALSE"
End iF

Print "okay"


[Charles Pegge]

They all work as expected here. Only the third case bypasses:

iF (a=2.0) > 2.0 
   print "FALSE 3"
End iF

[Frankolinox]

short question, I've tested the interesting "boolean" example, the last "false" result (third one) from peter isn't correct as result, but why? do you have fixed the problem charles in new oxygen dll or I am confused too? (must grinning)

servus, frank

[Mike Lobanovsky]

Gentlemen,

I don't quite get what all of you are talking about here. Peter's test script should work completely different if Oxygen's parentheses () are supposed to fulfill their intended purpose.

For example, the following conditional

if ((a = 2.0) < 2.0) // ML: C syntax proper

or its equivalent Oxygen conditional

if (a = 2.0) < 2.0 ' ML: O₂ syntax assumed hereinbelow for simplicity

would be analyzed in the C language as follows.

The () operator has the highest scope precedence in a statement. The sub-expression within the innermost parentheses (luckily there's only one nesting level in our case) is evaluated or executed the first. Here = is an assignment that makes a equal to 2.0 and this assignment is the very first thing the language does when evaluating the entire expression.

Further, C's parentheses also return their own temporary value which is equal to a result of the sub-expression that they immediately embrace. The result may be either arithmetical (as in our case above) or stringified (for example, a string produced as a result of concatenating several strings into one). Our sub-expression evaluates to 2.0, math-wise. This temporary result is valid for the purposes of boolean evaluation in the given if-block.

Whereby the initial expression may be reduced to simple

if 2.0 < 2.0 ' ML: ditto about syntax

which obviously evaluates to false. That is exactly why we shouldn't see the entire if-block print anything at all apart from doing at least one more useful thing that the programmer evidently wanted it to do, which was to assign 2.0 to the variable a.

From this standpoint, the following code:

Code: [Select]

sys a
iF a=1.0+1.0 = 2.0
   print "1.0+1.0 = 2.0 (TRUE ==> should print)"
End iF   

iF a=1.0+1.0 >= 2.0
   print "1.0+1.0 >= 2.0 (TRUE ==> should print)"
End iF   

iF (a=2.0) > 2.0 
   print "2.0 > 2.0 (FALSE ==> should NOT print at all!)"
End iF

iF (a=2.0) <> 2.0 
   print "2.0 <> 2.0 (FALSE ==> should NOT print at all!)"
End iF

iF (a=2.0) < 2.0
   print "2.0 < 2.0 (FALSE ==> should NOT print at all!)"
End iF

Print "okay"
does really strange things which I am inclined to regard as undefined behavior of Oxygen's parentheses.

It seems like we should ask Charles to revise his design decision again if he really wants Oxygen's parentheses to behave conventionally, because the above is very likely an outstanding bug. 

Regards,

[Charles Pegge]

There is a difference between the C '=' and Basic '=' in a conditional statement. You will find that in all of these statements, 'a' remains unaltered. However, these examples can be improved by using the unambiguous form '=='.

Another difference is that a boolean true produces an integer value of '-1', not '1'.

float a=0.0

if (a==2.0) > 2.0  'if 0 > 2
   print "3" 'never
end if

if (a==0) > 2.0 'if -1 > 2
  print "3a" 'never
end if

But I can't think of any practical situation where you would want to use such constructs

PS:

There is also a specific assignment operator for use in conditionals: ':='. Normally this would be used with a function returning a handle or error code

[Mike Lobanovsky]

Charles,

There is a difference between the C '=' and Basic '=' in a conditional statement.

Shouldn't it read Oxygen Basic given everything else I'm reading in this message?

You will find that in all of these statements, 'a' remains unaltered.

I am afraid, this contradicts (in fact, denies and ignores) all of the following:
1. scoping function of parentheses in an expression;
2. conventional BASIC usage of parentheses as a formal attribute of a function, i.e. an expression that returns a value, in this case, the value of 2.0; and finally
3. your own implementation of a = b = c ... = n.

There is absolutely nothing ambiguous, BASIC-wise, in such a parenthesized = which is unambiguously an assignment. Standard BASIC would decompose such an expression into:

a = 2.0
if a < 2.0 then ' in fact, "if 2.0 < 2.0 then" which means "never!"
...

However, these examples can be improved by using the unambiguous form '=='.

This operator is redundant if you follow standard BASIC conventions. In FBSL, == has a special meaning of "value and data type equality".

Another difference is that a boolean true produces an integer value of '-1', not '1'.

Again, this is irrelevant if you will follow standard BASIC conventions.

float a=0.0

if (a==2.0) > 2.0  'if 0 > 2
   print "3" 'never
end if

if (a==0) > 2.0 'if -1 > 2
  print "3a" 'never
end if

But I can't think of any practical situation where you would want to use such constructs

Neither can I.

There is also a specific assignment operator for use in conditionals: ':='. Normally this would be used with a function returning a handle or error code

As a language creator, you are free to use any alien operators however you see fit for your creation. But conventional BASIC operators should remain conventional in Oxygen Basic too IMHO.

Regards,

[Charles Pegge]

In Oxygen, the behaviour of '=' as a comparator, is governed by being in an if or while statement. (There is actually a switch available to override it #assign on)

Otherwise '=' is always an assignment operator. Hence the need to use '==' in a plain boolean statement.

sys a,b,c
c=(a==b) 'result c=-1

I have further mods in the pipeline, which will improve syntactic consistency:  for instance there are no comparator here

sys a,b,c
a=(b=c+1)+1
'results a=2, b=1, c=0

[Mike Lobanovsky]

Charles,

Be warned that you seem to be deliberately making your Basic code incompatible with every other BASIC in the world.



Why should you, really?

Regards,

[Mike Lobanovsky]

sys a,b,c
c=(a==b) 'result c=-1
...............................................
sys a,b,c
a=(b=c+1)+1
'results a=2, b=1, c=0

Please don't confuse these with what is there in Peter's code. These are a pretty different pair of shoes. There "shall not" (= mustn't, in Standard BASIC Specs' terms) be any special cases anywhere except those that are governed by the parentheses. And I repeat, from this standpoint, your == is a tautology, a redundancy, and an abuse. 3 in 1, as Nescafe goes.  

Your

c=(a==b)

is in fact

if a = b then c = -1 ' or c = true, for that matter

while

c = (a = b)

is unambiguously

let c, a = b ' in dialects where multi-let is allowed

or yet simpler

c = a = b ' in your own O₂

Moreover, your

a=(b=c+1)+1

is in fact

b = c + 1
a = b + 1

which is one character shorter than your one-liner!

Again, there's also a ternary iif(..., ..., ...). Isn't that supposed to be a Basic, after all? If yes then why bother, may I ask? What's in there in your semantics that can't be expressed in the existing clear and concise BASIC terms?  

P.S. OK OK, that will be all for today...

[Charles Pegge]

I thought BASIC was the preferred  language of rebels and renegades.

The only public ECMA BASIC I can see was published in 1978, but you have a copy of the 1986 standard there?
http://www.ecma-international.org/publications/files/ECMA-ST-WITHDRAWN/ECMA-55%20SCOPE.pdf

Oxygen borrows quite a few concepts from C and '==' is one of them. It will accept most C operators to aid porting, and to interpret C headers.

But what we are discussing here are new 'fringe' features, though a natural consequence of how the compiler works. I think they might lead somewhere interesting. I quite like the Multi-Let you mentioned, Mike, so maybe we could incorporate that as well.

Let a,b,c=42

[Mike Lobanovsky]

Aha, so both of us are not asleep yet. My premature desertion would be unfair to Oxygen Basic and its Creator.

O₂ has a very, very strong point. It is both an extremely efficient interpreter because of its underlying JIT compiler nature and it is also a static compiler with EXE and DLL capability. Plus, of course, its very well-developed inline assembly feature for the ultimate gurus into the bargain.

You shouldn't decorate all this treasure with C-ish extras that add no real good to the existing BASIC armory. That would only erode its consistency and predictability for a wide variety of potential Oxygen Basic users. There's still a lot to be done to extend O₂ to modern realities and non-native platforms too. This is where I'd like to see O₂ heading for. In this respect, I do support what John is usually advocating though I don't normally do it in his uncompromisingly straight-forward manner.

P.S. 1. No, only Freestyle BASIC was.

2. Yup, multi-let is nice. FBSL has historically formulated it as a function call though in fact it is not:

Let(a, b, c) = 123

In FBSL, () are a mandatory formal attribute of a fully qualified (executable) function call. Function names used without the parentheses are what we call volatiles (hehe, in fact non-volatiles) - they preserve the most recent fully qualified call's return value until  a subsequent fully qualified call to the same function is made. This helps avoid unnecessary temp vars and assignments. Sort of code optimization, speed-wise.

3. I'm sending you my copy of Standard BASIC Specs in a PM. There wasn't any newer Specs issued after 1986 to the best of my knowledge.

Kind regards,

[Mike Lobanovsky]

Sorry Charles, the zip (7z) is over 50MB in size; the forum won't accept such an attachment. I must go out to my bank before it closes down for today. I'll send you a link as soon as I'm back which will be in about 2 hours from now.

Sorry again for the inconvenience even if it's beyond my direct control, and see you soon.

[JRS]

I thought BASIC was the preferred  language of rebels and renegades.

Mike,

Have a look at Nimrod is you want to see a language built from the best syntax of many different language concepts. BASIC is going on 60 years old and it only seems logical to modernize the language for todays needs. I make sure I'm not idle with SB in any direction for too long as I don't want it labeled as one thing or another. I think Charles feels the same way about O2. IMHO

John