Is it common to use:

declare integer constant TRUE = -1
declare integer constant FALSE = 0


?

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/31/2025 10:18, Arne Vajhøj wrote:

Is it common to use:

declare integer constant TRUE = -1
declare integer constant FALSE = 0

Yeah, I've seen that a lot, especially code that started on the PDP-11.

--
-- Rob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/31/2025 10:28 AM, Robert A. Brooks wrote:

On 1/31/2025 10:18, Arne Vajhøj wrote:

Is it common to use:

declare integer constant TRUE = -1
declare integer constant FALSE = 0

Yeah, I've seen that a lot, especially code that started on the PDP-11.

In this case it is brand new code being written on VMS x86-64.

But there are special circumstances. I want to write the
same code in Pascal, Basic and Cobol. I started writing the
Pascal version. And I used true and false.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 31/01/2025 16:03, Arne Vajhøj wrote:

On 1/31/2025 10:28 AM, Robert A. Brooks wrote:

On 1/31/2025 10:18, Arne Vajhøj wrote:

Is it common to use:

declare integer constant TRUE = -1
declare integer constant FALSE = 0

Yeah, I've seen that a lot, especially code that started on the PDP-11.

In this case it is brand new code being written on VMS x86-64.

But there are special circumstances. I want to write the
same code in Pascal, Basic and Cobol. I started writing the
Pascal version. And I used true and false.

Arne

I often get confused which languages/variants redefine True and False. I
can find many thousands in my old codebase!

--
Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/31/2025 10:18 AM, Arne Vajhøj wrote:

Is it common to use:

declare integer constant TRUE = -1
declare integer constant FALSE = 0

?

Arne

It works. Doesn't really matter if declared a constant. Zero is false, anything else is true. Using 1 vs -1 has been more my experience.

Perhaps the concept of true and false isn't as clear in Basic as in some languages.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 31/01/2025 16:39, Dave Froble wrote:

On 1/31/2025 10:18 AM, Arne Vajhøj wrote:

Is it common to use:

declare integer constant TRUE = -1
declare integer constant FALSE = 0


?

Arne

It works.  Doesn't really matter if declared a constant.  Zero is false, anything else is true.  Using 1 vs -1 has been more my experience.

Perhaps the concept of true and false isn't as clear in Basic as in some languages.

I am surprised that 1 works if you using it on the result of a logical operation - it is documented:

EXPRESSIONS

Truth_values

In relational expressions, BASIC generates -1 when the relationship
is true and 0 when it is false. In logical expressions, BASIC
evaluates any nonzero value as true; zero is always evaluated as
false. To avoid unanticipated results, use logical operators
on the results of relational expressions.


--
Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/31/2025 11:39 AM, Dave Froble wrote:

On 1/31/2025 10:18 AM, Arne Vajhøj wrote:

Is it common to use:

declare integer constant TRUE = -1
declare integer constant FALSE = 0


?

It works.  Doesn't really matter if declared a constant.  Zero is false, anything else is true.  Using 1 vs -1 has been more my experience.

I got the impression that the manual/compiler prefer -1 over 1.

print not 0%

does print -1.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/31/25 07:18, Arne Vajhøj wrote:

Is it common to use:

declare integer constant TRUE = -1
declare integer constant FALSE = 0

?

Arne

That's been a standard for a long time.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/31/2025 1:28 PM, Simon Clubley wrote:

On 2025-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:

Is it common to use:

declare integer constant TRUE = -1
declare integer constant FALSE = 0

Oh goody. The "good" old days, when TRUE did not equal TRUE, are back. :-)

Some old some new.

C and VMS Basic are old.

But some newer script languages also have a
"flexible approach" to true/false.

$ type bool.php
<?php

function test($expr) {
echo ($expr ? 'true' : 'false') . "\r\n";
}

test(true);
test(false);
test(1);
test(0);
test(-1);
test("X");
test("");
test(null);


$ php bool.php
true
false
true
false
true
true
false
false

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/31/2025 1:35 PM, Arne Vajhøj wrote:

On 1/31/2025 1:28 PM, Simon Clubley wrote:

On 2025-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:

Is it common to use:

declare integer constant TRUE = -1
declare integer constant FALSE = 0

Oh goody. The "good" old days, when TRUE did not equal TRUE, are
back. :-)

Some old some new.

C and VMS Basic are old.

But some newer script languages also have a
"flexible approach" to true/false.

$ type bool.php
<?php

function test($expr) {
    echo ($expr ? 'true' : 'false') . "\r\n";
}

test(true);
test(false);
test(1);
test(0);
test(-1);
test("X");
test("");
test(null);

$ php bool.php
true
false
true
false
true
true
false
false

$ type bool.py
def test(expr):
print("true" if expr else "false")

test(True)
test(False)
test(1)
test(0)
test(-1)
test("X")
test("")
test(None)
$ python bool.py
true
false
true
false
true
true
false
false

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-01-31, Arne Vajh°j <arne@vajhoej.dk> wrote:

Is it common to use:

declare integer constant TRUE = -1
declare integer constant FALSE = 0

Oh goody. The "good" old days, when TRUE did not equal TRUE, are back. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <679d001e$0$713$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:

On 1/31/2025 11:39 AM, Dave Froble wrote:

On 1/31/2025 10:18 AM, Arne Vajhøj wrote:

Is it common to use:

declare integer constant TRUE = -1
declare integer constant FALSE = 0


?

It works.  Doesn't really matter if declared a constant.  Zero is false, >> anything else is true.  Using 1 vs -1 has been more my experience.

I got the impression that the manual/compiler prefer -1 over 1.

print not 0%

does print -1.

This sort of makes some sense when one considers the bit
representation of `-1` on a 2s complement machine (all bits 1).

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <679d18c2$0$713$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:

On 1/31/2025 1:35 PM, Arne Vajhøj wrote:

On 1/31/2025 1:28 PM, Simon Clubley wrote:

On 2025-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:

Is it common to use:

declare integer constant TRUE = -1
declare integer constant FALSE = 0

Oh goody. The "good" old days, when TRUE did not equal TRUE, are
back. :-)

Some old some new.

C and VMS Basic are old.

But some newer script languages also have a
"flexible approach" to true/false.

$ type bool.php
<?php

function test($expr) {
    echo ($expr ? 'true' : 'false') . "\r\n";
}

test(true);
test(false);
test(1);
test(0);
test(-1);
test("X");
test("");
test(null);

$ php bool.php
true
false
true
false
true
true
false
false

$ type bool.py
def test(expr):
print("true" if expr else "false")

test(True)
test(False)
test(1)
test(0)
test(-1)
test("X")
test("")
test(None)
$ python bool.py
true
false
true
false
true
true
false
false

If you really want to have a good time, look at how
JavaScript deals with this. Things aren't just true
or false, they're truthy and falsy, and sometimes Nan.

https://www.youtube.com/watch?v=et8xNAc2ic8

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/31/2025 2:24 PM, Dan Cross wrote:

In article <679d001e$0$713$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:

On 1/31/2025 11:39 AM, Dave Froble wrote:

On 1/31/2025 10:18 AM, Arne Vajhøj wrote:

Is it common to use:

declare integer constant TRUE = -1
declare integer constant FALSE = 0


?

It works.  Doesn't really matter if declared a constant.  Zero is false, >>> anything else is true.  Using 1 vs -1 has been more my experience.

I got the impression that the manual/compiler prefer -1 over 1.

print not 0%

does print -1.

This sort of makes some sense when one considers the bit
representation of `-1` on a 2s complement machine (all bits 1).

True.

But there is no consistency between languages.

$ type dump.for
subroutine dump(v)
integer*4 v
write(*,*) v
end
$ for dump
$ type logfun.for
program logfun
call dump(.true.)
call dump(.false.)
end
$ for logfun
$ link logfun + dump
$ run logfun
-1
0
$ type logfun.pas
program logfun(input,output);

[external]
procedure dump(%ref v : boolean); external;

begin
dump(true);
dump(false);
end.
$ pas logfun
$ link logfun + dump
$ run logfun
1
0

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 31/01/2025 19:24, Dan Cross wrote:

In article <679d001e$0$713$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:

On 1/31/2025 11:39 AM, Dave Froble wrote:

On 1/31/2025 10:18 AM, Arne Vajhøj wrote:

Is it common to use:

declare integer constant TRUE = -1
declare integer constant FALSE = 0


?

It works.  Doesn't really matter if declared a constant.  Zero is false, >>> anything else is true.  Using 1 vs -1 has been more my experience.

I got the impression that the manual/compiler prefer -1 over 1.

print not 0%

does print -1.

This sort of makes some sense when one considers the bit
representation of `-1` on a 2s complement machine (all bits 1).

- Dan C.

That was my understanding, a bitwise True and False should return zero
(False)

--
Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <679d26bd$0$713$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:

On 1/31/2025 2:24 PM, Dan Cross wrote:

In article <679d001e$0$713$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:

On 1/31/2025 11:39 AM, Dave Froble wrote:

On 1/31/2025 10:18 AM, Arne Vajhøj wrote:

Is it common to use:

declare integer constant TRUE = -1
declare integer constant FALSE = 0


?

It works.  Doesn't really matter if declared a constant.  Zero is false, >>>> anything else is true.  Using 1 vs -1 has been more my experience.

I got the impression that the manual/compiler prefer -1 over 1.

print not 0%

does print -1.

This sort of makes some sense when one considers the bit
representation of `-1` on a 2s complement machine (all bits 1).

True.

But there is no consistency between languages.

$ type dump.for
[snip]

I don't know why this should be surprising?

For Pascal, the integer values of `true` and `false` are given
in the standards documents (from e.g., ISO/IEC 7185:1990(E) sec
6.4.2.2. para (c): "The ordinal numbers of the truth values
denoted by *false* and *true* shall be the integer values 0 and
1 respectively."

In C, the relevant standards and most historical compilers treat
0 as false and anything non-zero as true and the negation
operator turns 0 into a 1 (I'm not sure how far back this goes).

Treating -1 as true in BASIC seems rather common, from the quick
survey I did; I speculate that this is almost certainly due to
the bit representation of -1 having all bits set, while in BASIC
the integer type is (usually?) signed, thus -1 on a two's
complement machine. I wonder what the original DTSS BASIC did?

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <vnjat2$3hjku$1@dont-email.me>,
Chris Townley <news@cct-net.co.uk> wrote:

On 31/01/2025 19:24, Dan Cross wrote:

In article <679d001e$0$713$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:

On 1/31/2025 11:39 AM, Dave Froble wrote:

On 1/31/2025 10:18 AM, Arne Vajhøj wrote:

Is it common to use:

declare integer constant TRUE = -1
declare integer constant FALSE = 0


?

It works.  Doesn't really matter if declared a constant.  Zero is false, >>>> anything else is true.  Using 1 vs -1 has been more my experience.

I got the impression that the manual/compiler prefer -1 over 1.

print not 0%

does print -1.

This sort of makes some sense when one considers the bit
representation of `-1` on a 2s complement machine (all bits 1).

That was my understanding, a bitwise True and False should return zero >(False)

Surely the same is true of 0 and 1, though? Perhaps a bitwise
AND of some value and TRUE should never be 0 unless that value
is 0.

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 31 Jan 2025 13:38:58 -0500, Arne Vajhøj wrote:

$ type bool.py
def test(expr):
print("true" if expr else "false")

Trying to shortcut your language design by not having an explicit boolean
type is a really bad idea.

<https://lwn.net/Articles/590299/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/31/2025 2:38 PM, Arne Vajhøj wrote:

$ type dump.for
      subroutine dump(v)
      integer*4 v
      write(*,*) v
      end
$ for dump
$ type logfun.for
      program logfun
      call dump(.true.)
      call dump(.false.)
      end
$ for logfun
$ link logfun + dump
$ run logfun
         -1
          0

Fortran got some other rather unique usages
of logicals:

$ type morelogfun.for
program morelogfun
logical*1 a(12)
data a/1hH,1he,1hl,1hl,1ho,1h ,1hw,1ho,1hr,1hl,1hd,1h!/
integer*4 i
write(*,*) (a(i),i=1,12)
write(*,'(1x,12a1)') (a(i),i=1,12)
end
$ for morelogfun
$ lin morelogfun
$ run morelogfun
F T F F T F T T F F F T
Hello world!

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/31/25 4:05 PM, Dan Cross wrote:

Treating -1 as true in BASIC seems rather common, from the quick
survey I did; I speculate that this is almost certainly due to
the bit representation of -1 having all bits set, while in BASIC
the integer type is (usually?) signed, thus -1 on a two's
complement machine. I wonder what the original DTSS BASIC did?

I had a quick look at:

https://ia601901.us.archive.org/34/items/bitsavers_dartmouthB_3679804/BASIC_4th_Edition_Jan68_text.pdf

and didn't see an obvious answer, though I didn't read the whole thing
and could've missed something. The exact values of true and false might
well have been considered an implementation detail that should not be
relied on.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/31/2025 11:53 AM, Arne Vajhøj wrote:

On 1/31/2025 11:39 AM, Dave Froble wrote:

On 1/31/2025 10:18 AM, Arne Vajhøj wrote:

Is it common to use:

declare integer constant TRUE = -1
declare integer constant FALSE = 0


?

It works. Doesn't really matter if declared a constant. Zero is false,
anything else is true. Using 1 vs -1 has been more my experience.

I got the impression that the manual/compiler prefer -1 over 1.

Manuals usually have a preference, but, can be incomplete.

print not 0%

does print -1.

That is an operation to flip the bits. The opposite of 0000000000000000 is 1111111111111111 ...


--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/31/2025 6:42 PM, Craig A. Berry wrote:

On 1/31/25 4:05 PM, Dan Cross wrote:

Treating -1 as true in BASIC seems rather common, from the quick
survey I did; I speculate that this is almost certainly due to
the bit representation of -1 having all bits set, while in BASIC
the integer type is (usually?) signed, thus -1 on a two's
complement machine.  I wonder what the original DTSS BASIC did?

I had a quick look at:

https://ia601901.us.archive.org/34/items/bitsavers_dartmouthB_3679804/ BASIC_4th_Edition_Jan68_text.pdf

and didn't see an obvious answer, though I didn't read the whole thing
and could've missed something.  The exact values of true and false might well have been considered an implementation detail that should not be
relied on.

Or maybe true and false did not exist.

I noted that the manual defined IF THEN as:

IF [formula] [relation] [formula] THEN [line number]

and not:

IF [formula] THEN [line number]

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/31/2025 1:28 PM, Simon Clubley wrote:

On 2025-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:

Is it common to use:

declare integer const

ant TRUE = -1

declare integer constant FALSE = 0

Oh goody. The "good" old days, when TRUE did not equal TRUE, are back. :-)

Simon.

Not sure what that means ...

In any case, consider testing for bit settings. Assume that the bit value "4", that's bit 2 set, and wanting to test for that particular bit.

If <variable/constant/whatever> AND 4 then print "True", else print "False"

If only -1 was "true", then that statement would not work. That would be rather
sad. So, non-zero being true is a good implementation.


--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/31/2025 7:38 PM, Dave Froble wrote:

On 1/31/2025 11:53 AM, Arne Vajhøj wrote:

On 1/31/2025 11:39 AM, Dave Froble wrote:

On 1/31/2025 10:18 AM, Arne Vajhøj wrote:

Is it common to use:

declare integer constant TRUE = -1
declare integer constant FALSE = 0


?

It works.  Doesn't really matter if declared a constant.  Zero is false, >>> anything else is true.  Using 1 vs -1 has been more my experience.

I got the impression that the manual/compiler prefer -1 over 1.

Manuals usually have a preference, but, can be incomplete.

print not 0%

does print -1.

That is an operation to flip the bits.  The opposite of 0000000000000000
is 1111111111111111 ...

Ah - yes. The manual say that NOT is bit wise but AND, OR and XOR
are logical.

<quote>
Operator Example Meaning
NOT NOT A% The bit-by-bit complement of A%. If A% is true (–1), NOT
A% is false (0).
AND A% AND B% The logical product of A% and B%. A% AND B% is true
only if both A% and B% are true.
OR A% OR B% The logical sum of A% and B%. A% OR B% is false only if
both A% and B% are false; otherwise, A% OR B% is true.
XOR A% XOR B% The logical exclusive OR of A% and B%. A% XOR B% is
true if either A% or B% is true but not if both are true.
</quote>

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/31/2025 5:05 PM, Dan Cross wrote:

In article <679d26bd$0$713$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:

But there is no consistency between languages.

$ type dump.for
[snip]

I don't know why this should be surprising?

I don't know if it is surprising, but it is inconsistent.

Fortran Pascal C Basic
true literal -1 1 usually 1 usually -1
false literal 0 0 0 0
test low bit set low bit set not 0 not 0

4 languages - 4 ways of doing it.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/31/2025 8:38 PM, Arne Vajhøj wrote:

On 1/31/2025 5:05 PM, Dan Cross wrote:

In article <679d26bd$0$713$14726298@news.sunsite.dk>,
Arne Vajhøj  <arne@vajhoej.dk> wrote:

But there is no consistency between languages.

$ type dump.for
[snip]

I don't know why this should be surprising?

I don't know if it is surprising, but it is inconsistent.

                 Fortran       Pascal        C          Basic
true literal       -1             1      usually 1    usually -1
false literal       0             0          0            0
test            low bit set  low bit set   not 0        not 0

4 languages - 4 ways of doing it.

Regarding the test:

$ type m.pas
program m(input,output);

type
ia5 = array [1..5] of integer;

[external]
procedure b(%ref v : ia5); external;

var
v : ia5;

begin
v[1] := -2;
v[2] := -1;
v[3] := 0;
v[4] := 1;
v[5] := 2;
b(v);
end.
$ type b.bas
sub b(integer v() by ref)
external string function s(integer)
external sub f(integer dim() by ref)
print using "Basic : 'E 'E 'E 'E 'E", s(v(0)), s(v(1)), s(v(2)), s(v(3)), s(v(4))
call f(v())
end sub
!
function string s(integer v1)
if v1 then
s = "TRUE "
else
s = "FALSE"
end if
end function
$ type f.for
subroutine f(v)
logical*4 v(5)
write(*,'(1x,a,5(l,4x))') 'Fortran :',v(1),v(2),v(3),v(4),v(5)
call c(v)
end
$ type c.c
#include <stdio.h>

void p(int *v);

void c(int *v)
{
printf("C :");
for(int i = 0; i < 5; i++) {
if(v[i]) {
printf(" TRUE ");
} else {
printf(" FALSE");
}
}
printf("\n");
p(v);
}
$ type p.pas
module p(input, output);

type
ia5 = array [1..5] of boolean;

[global]
procedure p(v : ia5);

begin
writeln('Pascal : ', v[1]:1, ' ', v[2]:1, ' ', v[3]:1, '
', v[4]:1, ' ', v[5]:1);
end;

end.
$ pas m
$ bas b
$ for f
$ cc c
$ pas p
$ link m + b + f + c + p
$ run m
Basic : TRUE TRUE FALSE TRUE TRUE
Fortran : F T F T F
C : TRUE TRUE FALSE TRUE TRUE
Pascal : F T F T F

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <679d7b05$0$713$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:

On 1/31/2025 5:05 PM, Dan Cross wrote:

In article <679d26bd$0$713$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:

But there is no consistency between languages.

$ type dump.for
[snip]

I don't know why this should be surprising?

I don't know if it is surprising, but it is inconsistent.

What I mean is, why is it notable that they are inconsistent?
They are, after all, different languages that come from
different places and took different evolutionary paths. They
have different standards defining them and mandating different
things; Pascal and C, define the values of the boolean literals
as 0 and 1; C goes further and mandates that the allowable
values in a `bool` are 0 (false) and 1 (true). The reference
manuals for the versions of BASIC and Fortran in use here
mandate that -1 is the value for the `false` literal.

Fortran Pascal C Basic
true literal -1 1 usually 1 usually -1
false literal 0 0 0 0
test low bit set low bit set not 0 not 0

These program snippets conflate two separate things: whether an
integer, when evaluated in a boolean context, yields a `true` or
`false` value, and the value that represents a literal `true`
constant.

4 languages - 4 ways of doing it.

Four different syntaxes, too. :-)

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/31/2025 8:39 PM, Arne Vajhøj wrote:

Regarding the test:

Basic   : TRUE  TRUE  FALSE TRUE  TRUE
Fortran : F     T     F     T     F
C       : TRUE  TRUE  FALSE TRUE  TRUE
Pascal  : F     T     F     T     F

Improved version:
* more values
* also pass individual values instead of array
* dump addresses for verification
* also try C bool for individual values (we are
past 1999)

$ type m.pas
program m(input,output);

type
ia9 = array [1..9] of integer;

[external]
procedure b1(%ref v : ia9); external;

[external]
procedure b2(%ref v1, v2, v3, v4, v5, v6, v7, v8, v9 : integer); external;

var
v : ia9;
i : integer;

begin
v[1] := -257;
v[2] := -256;
v[3] := -2;
v[4] := -1;
v[5] := 0;
v[6] := 1;
v[7] := 2;
v[8] := 256;
v[9] := 257;
write(' ');
for i := 1 to 9 do begin
write(v[i]:4, ' ');
end;
writeln;
b1(v);
b2(v[1], v[2], v[3], v[4], v[5], v[6], v[7], v[8], v[9]);
end.
$ type b.bas
sub b1(integer v() by ref)
external string function s(integer)
external sub f1(integer dim() by ref)
print using "Basic (array arg) : 'E 'E 'E 'E 'E 'E 'E 'E 'E (##########-##########)", &
s(v(0)), s(v(1)), s(v(2)), &
s(v(3)), s(v(4)), s(v(5)), &
s(v(6)), s(v(7)), s(v(8)), &
loc(v(0)), loc(v(8))
call f1(v())
end sub
!
sub b2(integer v1 by ref, integer v2 by ref, integer v3 by ref, &
integer v4 by ref, integer v5 by ref, integer v6 by ref, &
integer v7 by ref, integer v8 by ref, integer v9 by ref)
external string function s(integer)
external sub f2(integer by ref, integer by ref, integer by ref, &
integer by ref, integer by ref, integer by ref, &
integer by ref, integer by ref, integer by ref)
print using "Basic (multi arg) : 'E 'E 'E 'E 'E 'E 'E 'E 'E (##########-##########)", &
s(v1), s(v2), s(v3), &
s(v4), s(v5), s(v6), &
s(v7), s(v8), s(v9), &
loc(v1), loc(v9)
call f2(v1, v2, v3, v4, v5, v6, v7, v8, v9)
end sub
!
function string s(integer v1)
if v1 then
s = "TRUE "
else
s = "FALSE"
end if
end function
$ type f.for
subroutine f1(v)
logical*4 v(9)
integer*4 i
write(*,'(1x,a,9(l,4x),1x,1h(,i10,1h-,i10,1h))')
+ 'Fortran (array arg) :',
+ (v(i),i=1,9),
+ loc(v(1)),loc(v(9))
call c1(v)
end
c
subroutine f2(v1,v2,v3,v4,v5,v6,v7,v8,v9)
logical*4 v1,v2,v3,v4,v5,v6,v7,v8,v9
write(*,'(1x,a,9(l,4x),1x,1h(,i10,1h-,i10,1h))')
+ 'Fortran (multi arg) :',
+ v1,v2,v3,v4,v5,v6,v7,v8,v9,
+ loc(v1),loc(v9)
call c2a(v1,v2,v3,v4,v5,v6,v7,v8,v9)
call c2b(v1,v2,v3,v4,v5,v6,v7,v8,v9)
end
$ type c.c
#include <stdio.h>
#include <stdbool.h>

void p1(int *v);
void p2(int *v1, int *v2, int *v3, int *v4, int *v5, int *v6, int *v7,
int *v8, int *v9);

#define PTF(v) if(v) printf(" TRUE "); else printf(" FALSE");

void c1(int *v)
{
printf("C (array arg, int) :");
for(int i = 0; i < 9; i++)
{
PTF(v[i])
}
printf(" (%d-%d)\n", (int)&v[0], (int)&v[8]);
p1(v);
}

void c2a(int *v1, int *v2, int *v3, int *v4, int *v5, int *v6, int *v7,
int *v8, int *v9)
{
printf("C (multi arg, int) :");
PTF(*v1)
PTF(*v2)
PTF(*v3)
PTF(*v4)
PTF(*v5)
PTF(*v6)
PTF(*v7)
PTF(*v8)
PTF(*v9)
printf(" (%d-%d)\n", (int)v1, (int)v9);
p2(v1, v2, v3, v4, v5, v6, v7, v8, v9);
}

void c2b(bool *v1, bool *v2, bool *v3, bool *v4, bool *v5, bool *v6,
bool *v7, bool *v8, bool *v9)
{
printf("C (multi arg, bool) :");
PTF(*v1)
PTF(*v2)
PTF(*v3)
PTF(*v4)
PTF(*v5)
PTF(*v6)
PTF(*v7)
PTF(*v8)
PTF(*v9)
printf(" (%d-%d)\n", (int)v1, (int)v9);
}

$ type p.pas
module p(input, output);

type
ba9 = array [1..9] of boolean;

[global]
procedure p1(var v : ba9);

begin
writeln('Pascal (array arg) : ', v[1]:1, ' ', v[2]:1, ' ',
v[3]:1, ' ',
v[4]:1, ' ', v[5]:1, ' ',
v[6]:1, ' ',
v[7]:1, ' ', v[8]:1, ' ',
v[9]:1,
' (', iaddress(v[1]):1, '-', iaddress(v[9]):1, ')');
end;

[global]
procedure p2(var v1, v2, v3, v4, v5, v6, v7, v8, v9 : boolean);

begin
writeln('Pascal (multi arg) : ', v1:1, ' ', v2:1, ' ',
v3:1, ' ',
v4:1, ' ', v5:1, ' ',
v6:1, ' ',
v7:1, ' ', v8:1, ' ', v9:1,
' (', iaddress(v1):1, '-', iaddress(v9):1, ')');
end;

end.
$ pas m
$ bas b
$ for f
$ cc c
$ pas p
$ link m + b + f + c + p
$ run m
-257 -256 -2 -1 0 1 2 256 257 Basic (array arg) : TRUE TRUE TRUE TRUE FALSE TRUE TRUE TRUE
TRUE (2060040448 2060040480)
Fortran (array arg) : T F F T F T F F T
(2060040448-2060040480)
C (array arg, int) : TRUE TRUE TRUE TRUE FALSE TRUE TRUE TRUE
TRUE (2060040448-2060040480)
Pascal (array arg) : T F F T F T F F T
(2060040448-2060040480)
Basic (multi arg) : TRUE TRUE TRUE TRUE FALSE TRUE TRUE TRUE
TRUE (2060040448 2060040480)
Fortran (multi arg) : T F F T F T F F T
(2060040448-2060040480)
C (multi arg, int) : TRUE TRUE TRUE TRUE FALSE TRUE TRUE TRUE
TRUE (2060040448-2060040480)
Pascal (multi arg) : T F F T F T F F T
(2060040448-2060040480)
C (multi arg, bool) : TRUE FALSE TRUE TRUE FALSE TRUE TRUE FALSE
TRUE (2060040448-2060040480)

(in case someone wonder about C bool, then it is 8 bit!)

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <679e8b61$0$708$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:

On 1/31/2025 8:39 PM, Arne Vajhøj wrote:
Improved version:
* more values
* also pass individual values instead of array
* dump addresses for verification
* also try C bool for individual values (we are
past 1999)

You should really be clear about what, exactly, these programs
are showing. Again, I believe that most of what the specific
combination of languages and compilers at play here treat
different integers, when used in a boolean context. But all of
that can easily be determined from the relevant language or ABI
documentation.

[snip]

(in case someone wonder about C bool, then it is 8 bit!)

Sure. That's specified by the ABI.

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/1/2025 6:38 PM, Craig A. Berry wrote:

On 2/1/25 3:00 PM, Arne Vajhøj wrote:

(in case someone wonder about C bool, then it is 8 bit!)

I don't think it has to be.  C99 says:

"An object declared as type _Bool is large enough to store the values 0
and 1."

8 bits are enough, but any integral type has enough bits.  "bool,"
"true," and "false" in stdbool.h are macros that can be overridden,
although doing so is described as "obsolescent" behavior.  It's probably necessary because of the uses of bool before the standard had it.

I'm pretty sure I've seen bool defined as an int on VMS, but whether
that was something VAX C did for you or was just some what some program
did in the absence of anything available from the (old) compiler I don't remember.

The C standard does not mandate 8 bit.

The VMS C documentation says 8 bit. Well - it says 1 byte
for whatever reason, but ...

<quote>
3.2. Integral Types
In C, an integral type can declare:

Integer values, signed or unsigned

Boolean values, where 0 is equivalent to false and any nonzero
number is equivalent to true

Characters, which are automatically converted to an integer value
by the compiler

Members of an enumerated type, which are interpreted as an integer
by the compiler

Bit fields

The integral types are:

char, signed char, unsigned char – 8 bits

short int, signed short int, and unsigned short int – 16 bits

_Bool – 1 byte

int, signed int, unsigned int – 32 bits

long int, signed long int, and unsigned long int – 32 bits

signed long long int and unsigned long long int – 64 bits

signed __int64 and unsigned __int64 – 64 bits

enum – 32 bits
</quote>

If one include stdbool.h then bool is _Bool. From C 99.

Before C 99 then I think:

typedef int bool;
#define TRUE 1
#define FALSE 0

was common.

(stdbool.h also defines true and false)

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/1/25 3:00 PM, Arne Vajhøj wrote:

(in case someone wonder about C bool, then it is 8 bit!)

I don't think it has to be. C99 says:

"An object declared as type _Bool is large enough to store the values 0
and 1."

8 bits are enough, but any integral type has enough bits. "bool,"
"true," and "false" in stdbool.h are macros that can be overridden,
although doing so is described as "obsolescent" behavior. It's probably necessary because of the uses of bool before the standard had it.

I'm pretty sure I've seen bool defined as an int on VMS, but whether
that was something VAX C did for you or was just some what some program
did in the absence of anything available from the (old) compiler I don't remember.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 31 Jan 2025 10:18:00 -0500, Arne Vajhøj wrote:

Is it common to use:

declare integer constant TRUE = -1
declare integer constant FALSE = 0

?

I can remember on the Motorola 68000, false was 0 (all bits clear) and
true was -1 (all bits set). Being a Pascal fan at the time, I thought this
was really a bad idea. In Pascal you have the equivalant of

type
boolean = (false, true);

so false clearly maps to 0 and true to 1.

Why is it important to insist on this? So that you can use boolean, like
any other discrete type, as an array index type. E.g.

var
double_buffer : array [boolean] of buffer;
thisbuf : boolean;

Glad to see that C99 sort-of agrees with Pascal. Certainly it says the
only *defined* values of bool type are 0 for false and 1 for true.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 31 Jan 2025 17:20:11 -0500, Arne Vajhøj wrote:

F T F F T F T T F F F T
Hello world!

Clearly it is only looking at the bottom bit.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <679eb699$0$708$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:

On 2/1/2025 6:38 PM, Craig A. Berry wrote:

On 2/1/25 3:00 PM, Arne Vajhøj wrote:

(in case someone wonder about C bool, then it is 8 bit!)

I don't think it has to be.  C99 says:

"An object declared as type _Bool is large enough to store the values 0
and 1."

8 bits are enough, but any integral type has enough bits.  "bool,"
"true," and "false" in stdbool.h are macros that can be overridden,
although doing so is described as "obsolescent" behavior.  It's probably
necessary because of the uses of bool before the standard had it.

Gone away in C23. `bool`, `false`, and `true` are now keywords,
and thus reserved. See n3220, sec 6.4.1 paras (1) and (2). https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf

I'm pretty sure I've seen bool defined as an int on VMS, but whether
that was something VAX C did for you or was just some what some program
did in the absence of anything available from the (old) compiler I don't
remember.

The C standard does not mandate 8 bit.

Correct. The C standard doesn't really concern itself with the
concerete representation of data types; that's up to the
implementation.

Most of the time, this is given by an ABI. For example, the
SVR4 ABI for x86_64 used on most modern Unix-y systems on that
platform defines the size of _Bool to be 1 byte. See https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/master/raw/x86-64-ABI/abi.pdf?job=build
(See figure 3.1, "Scalar Types", on page 17.)

Note that the OpenVMS calling standard for x86_64 closely
follows the System V ABI.
(https://vmssoftware.com/docs/VSI_CALLING_STD.pdf, sec C.2):

The VMS C documentation says 8 bit. Well - it says 1 byte
for whatever reason, but ...

The VMS ABI is derived from the System V ABI, and specifically
the AMD64 supplement, which defines "byte" to be an 8-bit
quantity in sec. 3.1.2:

|Within this specification, the term byte refers to a 8-bit
|object.

Note that the terms used in the SysV ABI for the larger
multibyte quantities are explicitly called out as things that
differ in the VMS Calling Standard, but this is understood to
mean nomenclature, not actual data layout.

If one include stdbool.h then bool is _Bool. From C 99.

Before C 99 then I think:

typedef int bool;
#define TRUE 1
#define FALSE 0

was common.

There were all sorts of variations before C99; this has led to
some headaches. Beyond the obvious issue of symbol conflicts,
people have tried to play tricks with e.g. `enum`s, a la,

typedef enum { false, true } bool;

but the issue here is that enums are really `int`s, and so so
if such things were used in, say, a `struct` in some
public-facing header, perhaps as part of a library that is
distributed in binary-form only,then you may have a breaking
change if linked against code that uses the newer ABI-mandated
representation. For example, consider a struct such as:

struct foo {
int a;
bool b;
char c;
};

On a system following the SysV AMD64 ABI, this is an 8-byte
type, with 4-byte alignment. But using the enum trick, it's a
12-byte type, with 4-byte alignment. Mismatched code beware.

(stdbool.h also defines true and false)

These are also now reserved keywords in C23.

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-01-31, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

If you really want to have a good time, look at how
JavaScript deals with this. Things aren't just true
or false, they're truthy and falsy, and sometimes Nan.

https://www.youtube.com/watch?v=et8xNAc2ic8

And we use this crap to build critical websites that our society and
general way of life now depend on. :-(

And some even think it's a good idea to run this server-side. :-(

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-01-31, Arne Vajh°j <arne@vajhoej.dk> wrote:

Fortran got some other rather unique usages
of logicals:

$ type morelogfun.for
program morelogfun
logical*1 a(12)
data a/1hH,1he,1hl,1hl,1ho,1h ,1hw,1ho,1hr,1hl,1hd,1h!/
integer*4 i
write(*,*) (a(i),i=1,12)
write(*,'(1x,12a1)') (a(i),i=1,12)
end
$ for morelogfun

DEC Fortran still allows Hollerith constants without having to specify
a compiler option to enable them ?

For people who do not know historical Fortran, see:

https://en.wikipedia.org/wiki/Hollerith_constant

Hollerith constants have been removed from the current Fortran language standards (and rightly so).

$ lin morelogfun
$ run morelogfun
F T F F T F T T F F F T
Hello world!

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-01-31, Dave Froble <davef@tsoft-inc.com> wrote:

On 1/31/2025 1:28 PM, Simon Clubley wrote:

On 2025-01-31, Arne Vajh°j <arne@vajhoej.dk> wrote:

Is it common to use:

declare integer const

ant TRUE = -1

declare integer constant FALSE = 0

Oh goody. The "good" old days, when TRUE did not equal TRUE, are back. :-) >>

Not sure what that means ...

In the old days, some people defined TRUE as -1, while others in the
same or related ecosystems defined TRUE as +1, hence TRUE did not
equal TRUE. It's been a long time, but I think I saw this back in the
Microsoft world back in the Windows 98/Windows 2000[1] days when calling modules written in different languages.

Simon.

[1] BTW, I still think the Windows 2000 UI was vastly superior to the
UI stuff we are forced to use these days...

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/3/2025 1:35 PM, Simon Clubley wrote:

On 2025-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:

Fortran got some other rather unique usages
of logicals:

$ type morelogfun.for
program morelogfun
logical*1 a(12)
data a/1hH,1he,1hl,1hl,1ho,1h ,1hw,1ho,1hr,1hl,1hd,1h!/
integer*4 i
write(*,*) (a(i),i=1,12)
write(*,'(1x,12a1)') (a(i),i=1,12)
end
$ for morelogfun

DEC Fortran still allows Hollerith constants without having to specify
a compiler option to enable them ?

For people who do not know historical Fortran, see:

https://en.wikipedia.org/wiki/Hollerith_constant

Hollerith constants have been removed from the current Fortran language standards (and rightly so).

It is an extension in VMS fortran.

And even though it is a horrible way to do text, then it
is not something one get to use accidentally.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 3 Feb 2025 15:39:37 -0500, Arne Vajhøj wrote:

[Hollerith] is an extension in VMS fortran.

And even though it is a horrible way to do text, then it is not
something one get to use accidentally.

Trouble is, every other notation for string literals requires some kind of escape system for representing characters that might interfere with the
syntax notation itself.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 3 Feb 2025 19:11 +0000 (GMT Standard Time), John Dallman wrote:

Every few years, somebody decides that computing can be made simpler by discarding the lessons of the past. Then they find have to re-invent the safety precautions and useful features of the past, and do it a bit differently.

As opposed to those who stick with running systems from the past, and
disregard lessons learned since those original products were created?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <vnr1lq$1d7as$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-01-31, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

If you really want to have a good time, look at how
JavaScript deals with this. Things aren't just true
or false, they're truthy and falsy, and sometimes Nan.

https://www.youtube.com/watch?v=et8xNAc2ic8

And we use this crap to build critical websites that our society and
general way of life now depend on. :-(

Yeah. Typescript is better, and shaves off a lot of the sharper
edges, but their ability to really fix things is limited by the
demands of backwards compatibility.

And some even think it's a good idea to run this server-side. :-(

Some people think that Javascript is actually a good language.
Doug Crockford wrote a book on the good parts; it is a rather
thin volume. :-)

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 3 Feb 2025 19:32:35 -0500, Arne Vajhøj wrote:

On 2/3/2025 5:05 PM, Lawrence D'Oliveiro wrote:

Trouble is, every other notation for string literals requires some kind
of escape system for representing characters that might interfere with
the syntax notation itself.

True. But that does not seem to be a problem.

I know. Normal people see it as an absolute nightmare to try to calculate
a count prefix. But surely any self-respecting editor makes that easy,
e.g.

44HThe quick brown fox jumps over the lazy dog.

It only took me a few seconds in Emacs, even without the benefit of a
custom command to make it faster.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/3/2025 5:05 PM, Lawrence D'Oliveiro wrote:

On Mon, 3 Feb 2025 15:39:37 -0500, Arne Vajhøj wrote:

[Hollerith] is an extension in VMS fortran.

And even though it is a horrible way to do text, then it is not
something one get to use accidentally.

Trouble is, every other notation for string literals requires some kind of escape system for representing characters that might interfere with the syntax notation itself.

True. But that does not seem to be a problem. Whether it is
because it is simple or because practical all developers
know the two main ways (doubling and backslash escape)
does not change that it work fine.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <vnrn73$1hm1g$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:

On 2/3/2025 5:05 PM, Lawrence D'Oliveiro wrote:

On Mon, 3 Feb 2025 15:39:37 -0500, Arne Vajhøj wrote:

[Hollerith] is an extension in VMS fortran.

And even though it is a horrible way to do text, then it is not
something one get to use accidentally.

Trouble is, every other notation for string literals requires some kind of >> escape system for representing characters that might interfere with the
syntax notation itself.

True. But that does not seem to be a problem. Whether it is
because it is simple or because practical all developers
know the two main ways (doubling and backslash escape)
does not change that it work fine.

Indeed, it's easy.

I don't understand why you continue to engage with Lawrence,
though. He's obviously a troll.

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/3/2025 8:18 PM, Lawrence D'Oliveiro wrote:

On Mon, 3 Feb 2025 19:32:35 -0500, Arne Vajhøj wrote:

On 2/3/2025 5:05 PM, Lawrence D'Oliveiro wrote:

Trouble is, every other notation for string literals requires some kind
of escape system for representing characters that might interfere with
the syntax notation itself.

True. But that does not seem to be a problem.

I know. Normal people see it as an absolute nightmare to try to calculate
a count prefix. But surely any self-respecting editor makes that easy,
e.g.

44HThe quick brown fox jumps over the lazy dog.

It only took me a few seconds in Emacs, even without the benefit of a
custom command to make it faster.

Note that the above seems to be a hollerith edit descriptor (deleted in
Fortran 95 standard) and not a hollerith constant (deleted in
Fortran 77 standard). Counting is not a problem in hollerith constants,
but changing the string can be.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <vnr1lq$1d7as$1@dont-email.me>, clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:

And we use this crap to build critical websites that our society and
general way of life now depend on. :-(

And some even think it's a good idea to run this server-side. :-(

Every few years, somebody decides that computing can be made simpler by discarding the lessons of the past. Then they find have to re-invent the
safety precautions and useful features of the past, and do it a bit differently.

John

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-01-31 16:18, Arne Vajhøj wrote:

Is it common to use:

declare integer constant TRUE = -1
declare integer constant FALSE = 0

?

After reading through this thread, I can offer a comment or two that
I've not seen anyone else bring up (and sorry for reviving a thread that
had stopped).

But first of all, while I haven't often seen those declarations as such,
they make perfect sense in BASIC.

What noone seems to have brought up is that BASIC don't really have a
boolean type, or logical operations on booleans.

There is no boolean AND for instance. There is only the numerical one.

If you do a statement like:

IF 1% AND 2% THEN PRINT "All true" ELSE PRINT "All false"

you'll get "All false".

Because while 1 and 2 both will be regarded as true (or rather not
false), AND isn't dealing with them that way. It just does a binary and
of the two values, and then you have an IF on the resulting value (which
would be 0 in this case).

So in that sense, it is good practice to use -1 for true, because then
at least TRUE and (whatever not false) is still (sortof) true.

It's also easy to observe that BASIC actually generally use -1 to
represent true.

Just try:

PRINT 1=1

for example. The output will be -1.

Here are the cut-n-paste from BASIC+2 for this:

.bp2

PDP-11 BASIC-PLUS-2 V2.7-C

BASIC2

print 1=1


-1

BASIC2

IF 1% AND 2% THEN PRINT "All true" ELSE PRINT "All false"


All false

BASIC2



Johnny

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)