Boolean Data Type in freebasic

[dkl]

That must be a "broken" build of the compiler (that wasn't bootstrapped correctly), it's exactly the issue we were talking about above. With a more recent 1.04.0 build it should work normally.

[St_W]

Sorry for the troubles with the last version of my builds and the downtime of the build machine yesterday that caused the unavailability of new (fixed) builds. The problem is exactly the bootstrapping issue discussed previously. Maybe I should change the build process to always build the compiler twice (something similar is already done for some x64 builds which probably weren't affected by the problem - although, I haven't tested it)? A self-hosting compiler doesn't make it easy to define a stable build process...
Anyway, I think having a clean code is usually more desirable than supporting old compiler versions (and introducing a lot of workarounds and redundancies to achieve that).

As mentioned in a previous post the build machine is up again and the new builds are online (and give the expected results).

Sorry again for the troubles caused.

[marcov]

A self-hosting compiler doesn't make it easy to define a stable build process...
Anyway, I think having a clean code is usually more desirable than supporting old compiler versions (and introducing a lot of workarounds and redundancies to achieve that).

Doing multiple times is pretty standard

0 build RTS with bootstrap compiler with defines that disable some functionality that the old version can't handle.
1. to build a new compiler with defines that disable some functionality that the old version can't handle.
1b. rebuild RTS. (in theory the compiler could have things disabled, so this is not "full")
2. rebuild a full compiler
2b. rebuild a full RTS with all optimizations enabled.
3. rebuild the final compiler with all optimizations
3b rebuild the RTS again to match the built compiler.

rarer:
4. (development build) do another step exactly like (3) and do a binary diff between 3 and 4. This detects issues by uninitialized variables in the compiler. Often this also already possible between (2) and (3), depending on how much shoehorning is needed to bootstrap.
(or)
5. (release build) whole program optimizations build with profiling feedback from earlier builds (3).

FPC does the first 3 steps standard, and the Whole program optimization only for release builds. The compiler part of the build is not make -j parallel. (but building packages and header is). The 3 recompiles take about 1 minute on a medium speed machine.

I've seen whole release builds in under a minute on heavy machines (like a i7-2500 with SSD under linux, windows is always 25% slower)

I don't think the auto-bootstrapping makes it that harder. Yes some things are different, but bootstrapping also provides some isolation from issues (like versioning of the compilers and libs that you use) in other systems. At least for the native backend, if the RTS were in the own language.

On windows, with the native linker, FPC can be bootstrapped with an old compiler and a batchfile, nothing else. (though in reality a mingw make and a few utils like pwd, rm etc are used)

Btw, do you have figures about bootstrapping times?

[dodicat]

I still get an integer return for > and <.
Is this correct?
I have just downloaded St_w's build.
I have used my previous snippet:

Code: Select all

 


function IsLeft(L1x as integer ,L1y as integer,L2x as integer,L2y as integer,px as integer,py as integer) as boolean
  return iif(Sgn((L1x-L2x)*(py-L2y)-(px-L2x)*(L1y-L2y))<0,true,false)
end function


screen 19
dim as integer mx,my
do
    getmouse mx,my
    screenlock
    cls
line(0,30)-(800,450)
locate 4,4
print "Move the mouse across the line",
print isleft(0,30,800,450,mx,my)

#print typeof(isleft(20,30,600,450,mx,my))
screenunlock
sleep 1,1
loop until len(inkey)
 dim as boolean x=true,y=false
    #print typeof(x>y)
    print "x= ",(x)
    print "y= ",(y)
    print
    print "x>y", (x>y)
    print "x<y",(x<y)
    print "x=y",(x=y)
    y=true
    print "y is now true"
    print "x and y", (y and x)
    print "x=y", (x=y)
    #print typeof(x and y)
    print sizeof(false),sizeof(x>y),sizeof(x<y)
    print __fb_version__ ''=1.04.0
    
    sleep

[St_W]

I still get an integer return for > and <.
Is this correct?
I have just downloaded St_w's build.

Please force a page refresh in your browser to ensure that you see the latest uploads. Usually this can be done by pressing CTRL+F5 or a similar F5-key combination.
Unfortunately the directory listings seem to get cached by (some?) browsers - I cannot do anything about that as it's Sebastian's server and I only have FTP access to that upload directory.
The builds which should work have the date "2015-07-27" in the filename (or newer builds in the future).
The builds having the date "2015-07-25" in the filename will show that integer instead of string issue.

[fxm]

If x and y are two booleans, why (x>y) should return also a bolean?
The '>', '<','>=' and '<=' operators only have meaning for numeric values (or strings).
I think that compiler makes an implicit conversion of boleans to integers before comparison (and then, no implicit conversion inverse on comparison result).

One solution is to use Cbool:
print "x>y",cbool(x>y)
print "x<y",cbool(x<y)

[dodicat]

Thanks St_W.
I have the latest GREEN build.

Thanks fxm.
I tested out a few with C++, for example = (= =) has size 1 byte and returns bool as FB.
Obviously the Fb boolean follows the C++ bool, this was the reason d'etra (excuse my French) for fb boolean in the first place!

[fxm]

...
Obviously the Fb boolean follows the C++ bool, this was the reason d'etra (excuse my French) for fb boolean in the first place!

???

[St_W]

I have the latest GREEN build.!

OK. I have just tested your code with the same build and a custom build on both x86 and x64 Windows and always get numeric results, so it shouldn't be an issue with my builds at least. Anyway, from my point of view the Operators ">" and "<" do not seem to make much sense for booleans, do they?

Obviously the Fb boolean follows the C++ bool, this was the reason d'etra (excuse my French) for fb boolean in the first place!

???

I'm sure you know, but maybe for others: https://en.wiktionary.org/wiki/raison_d%27%C3%AAtre
I also think that C++ compatibility was/is an important consideration during design and implementation of boolean for FB.

Doing multiple times is pretty Standard [...]

I've adapted my build jobs accordingly to build fbc two times for each new build in the future (except FreeBSD, which is a bit special). The process is a bit easier for fbc than your description for FPC, because the fbc's rtlib is written in C. The build now works like this:
1. Build rtlib, gfxlib2
2. Build Compiler using old/stable fbc Version
3. Build the Compiler again using the previous fbc build (step 2)
I hope that helps avoiding bootstrap issues in the future.

[dodicat]

Yes,
raison d'être
is better than reason d'etra.

I don't suppose the > or < operations need overloaded to return boolean.

Can't do anyway, at least not straight off.
error:
At least one parameter must be a user-defined type, at parameter 2 (y) of operator.>(as boolean, as boolean) as boolean in 'operator >(x as boolean,y as boolean) as boolean'

Here's another little tester, then I'm off outa here.

Code: Select all

#include "crt.bi"

Function isprime(N As ulongint) As boolean
    If (N=2) Or (N=3) Then Return true
    If N Mod 2=0 Then Exit Function
    If N Mod 3=0 Then Exit Function
    Dim limit As Double=Sqr(N)+1
    For i as integer =6 To limit Step 6
        If N Mod (i-1)=0 Then Exit Function
        If N Mod (i+1)=0 Then Exit Function
    Next I
    Function=true
End Function

dim fn as function(n as ulongint) as boolean

 fn=procptr(isprime)
 
 width 90,3050
for n as uinteger=1 to 3000
    var S=str(n)
    puts S &string(8-len(S)," ") &ucase(str(fn(n)))
next n
sleep


 

[coderJeff]

See https://github.com/jayrm/fbc/tree/boolean2

Made a couple changes:
- re-added cbool() usage back in the compiler, but also combining dkl's code so fbc will produce a working compiler in a 1-step build
- more aggressive about warning on mixing boolean and non-boolean types
- error on operators that don't make sense for booleans - only NOT AND OR XOR EQV IMP ANDALSO ORELSE <> = should be allowed

WIP:
- I still need to work through the errors for constant folding and warnings for mixing boolean and non-boolean constants. It's a different code pathway, and the initial version was much more permissive that where it's headed now.

Maybe change later:
- NEG - operator on boolean is still allowed because of the way cunit.bi header is written, otherwise test suite itself won't compile. cunit macros use comparison expressions as integers like "-(a <> b)" to give a 0|1 result. That could be fixed by changing header to -cint(a <> b)

Considering:
- ANDALSO, ORELSE returning boolean: That looks possible with some support added to the backends. If that change were made, then fbc would be making direct use of the boolean for logic. Would be good to be cautious on a change like this.
- comparison ops return boolean. Would be good to be *very* cautious on a change like this. In theory it's possible, but all other aspects of the boolean data type need to be reliably consistent, bug free, IMO.

[coderJeff]

I've adapted my build jobs accordingly to build fbc two times for each new build in the future

ST_W, thank you for sorting it out for everyone with your daily builds. Yeah, I get the impression that users are willing to try out a work in progress if it's available in a package, and less likely to build it from sources (even less likely to build from an alternate branch). Thanks.

[Tourist Trap]

- comparison ops return boolean. Would be good to be *very* cautious on a change like this. In theory it's possible, but all other aspects of the boolean data type need to be reliably consistent, bug free, IMO.

Does it mean that it wont be possible then to write something like :

Code: Select all

dim as integer a, b, result = -7*(a < b) -8*(a = b)-9*(a > b)

Code: Select all

"Returns either 7, or 8, or 9"

Or implicit conversion from boolean to integers would be implemented in order to avoid heavy scripture like :

• -7*CInt((a<b)) ?

[fxm]

Code: Select all

dim as boolean a, b
dim as integer result = -7*(a < b) -8*(a = b)-9*(a > b)

print (a < b), (a = b), (a > b)
print -7*(a < b), -8*(a = b), -9*(a > b)
print result

sleep

Code: Select all

 0            true           0
 0             8             0
 8

None any warning!

That is the present behavior:
- for 'a<b' and 'a>b', the booleans a and b are implicitly converted to integers before comparing
- for 'a=b', the result is a boolean
- for '-8*(a=b)', the boolean (a=b) is implicitly converted to integer before multiplying

- for a=false and b=false, result=8
- for a=false and b=true, result=9
- for a=true and b=false, result=7
- for a=true and b=true, result=8

[coderJeff]

That is the present behavior:
- for 'a<b' and 'a>b', the booleans a and b are implicitly converted to integers before comparing
- for 'a=b', the result is a boolean
- for '-8*(a=b)', the boolean (a=b) is implicitly converted to integer before multiplying

If by present behaviour you mean what is in freebasic/fbc/master repo right this second. I'm OK with this behaviour.

However, some suggested only certain operators should be allowed to be used with booleans. OK, I am trying that out in jayrm/fbc/boolean2 branch. If some operators are not allowed with boolean (e.g. math operators), then yes, error would be generated, unless explicit conversion (e.g. CINT()) is used.