basic BASIC question

[Arne Vajhøj]

Is it common to use:

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


?

Arne

[Robert A. Brooks]

Post by Arne Vajhøj
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.

[Arne Vajhøj]

Post by Robert A. Brooks

Post by Arne Vajhøj
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

[Chris Townley]

Post by Arne Vajhøj

Post by Robert A. Brooks

Post by Arne Vajhøj
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!

[jeffrey_dsi]

Post by Arne Vajhøj
declare integer constant TRUE = -1
declare integer constant FALSE = 0
?
Arne

That's been a standard for a long time.

[Dave Froble]

Post by Arne Vajhøj
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.

[Arne Vajhøj]

Post by Arne Vajhøj
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

[Dan Cross]

Post by Arne Vajhøj

Post by Arne Vajhøj
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.

[Arne Vajhøj]

Post by Dan Cross

Post by Arne Vajhøj

Post by Arne Vajhøj
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

[Dan Cross]

Post by Arne Vajhøj

Post by Dan Cross

Post by Arne Vajhøj

Post by Arne Vajhøj
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.

[Craig A. Berry]

Post by Dan Cross
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.

[Arne Vajhøj]

Post by Craig A. Berry

Post by Dan Cross
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?

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

[Arne Vajhøj]

Post by Dan Cross

Post by Arne Vajhøj
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

[Arne Vajhøj]

Post by Arne Vajhøj

Post by Dan Cross

Post by Arne Vajhøj
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

[Arne Vajhøj]

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

[Dan Cross]

Post by Arne Vajhøj
* 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.

Post by Arne Vajhøj
[snip]
(in case someone wonder about C bool, then it is 8 bit!)

Sure. That's specified by the ABI.

- Dan C.

[Craig A. Berry]

Post by Arne Vajhøj
(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.

[Arne Vajhøj]

Post by Craig A. Berry

Post by Arne Vajhøj
(in case someone wonder about C bool, then it is 8 bit!)

"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

[Dan Cross]

Post by Arne Vajhøj

Post by Craig A. Berry

Post by Arne Vajhøj
(in case someone wonder about C bool, then it is 8 bit!)

"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

Post by Arne Vajhøj

Post by Craig A. Berry
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.

Post by Arne Vajhøj
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.

Post by Arne Vajhøj
If one include stdbool.h then bool is _Bool. From C 99.
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.

Post by Arne Vajhøj
(stdbool.h also defines true and false)

These are also now reserved keywords in C23.

- Dan C.

[Dan Cross]

Post by Arne Vajhøj

Post by Dan Cross

Post by Arne Vajhøj
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.

Post by Arne Vajhøj
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.

Post by Arne Vajhøj
4 languages - 4 ways of doing it.

Four different syntaxes, too. :-)

- Dan C.

[Arne Vajhøj]

Post by Arne Vajhøj
$ 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

[Lawrence D'Oliveiro]

Post by Arne Vajhøj
F T F F T F T T F F F T
Hello world!

Clearly it is only looking at the bottom bit.

[Simon Clubley]

Post by Arne Vajhøj
Fortran got some other rather unique usages
$ 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).

Post by Arne Vajhøj
$ lin morelogfun
$ run morelogfun
F T F F T F T T F F F T
Hello world!

Simon.

[Arne Vajhøj]

Post by Simon Clubley

Post by Arne Vajhøj
Fortran got some other rather unique usages
$ 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 ?
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

[Lawrence D'Oliveiro]

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

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

[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

[Lawrence D'Oliveiro]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro
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.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro
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

[Lawrence D'Oliveiro]

Note that the above seems to be a hollerith edit descriptor ...

Never heard of such a thing.
<https://www.ibm.com/docs/en/openxl-fortran-aix/17.1.2?topic=constants-hollerith>

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Note that the above seems to be a hollerith edit descriptor ...

Never heard of such a thing.
<https://www.ibm.com/docs/en/openxl-fortran-aix/17.1.2?topic=constants-hollerith>

It is mentioned in the wikipedia article previously linked to.

Arne

[Lawrence D'Oliveiro]

Note that the above seems to be a hollerith edit descriptor ...

Ah, you are confusing usage with syntax.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Note that the above seems to be a hollerith edit descriptor ...

Ah, you are confusing usage with syntax.

It is two different things in the language.

Arne

[Lawrence D'Oliveiro]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Note that the above seems to be a hollerith edit descriptor ...

Ah, you are confusing usage with syntax.

It is two different things in the language.

Two different usages. Neither of which I mentioned in my example.

[Dan Cross]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

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

[Arne Vajhøj]

Post by Arne Vajhøj

Post by Simon Clubley

Post by Arne Vajhøj
Fortran got some other rather unique usages
$ 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 ?
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.

Note that it does give warnings with /STAND=F90 and
/STAND=F95.

But default is /NOSTAND (which really could have
been called /STAND=VAX in my opinion as VAX Fortran
is a thing).

The problem with /STAND=F9x is that it also give
warnings for other things that may be deemed less
important. For the above code logical*1 and integer*4
also gives warning with /STAND=F9x.

Arne

[Chris Townley]

Post by Dan Cross

Post by Arne Vajhøj

Post by Arne Vajhøj
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)

[Dan Cross]

Post by Chris Townley

Post by Dan Cross

Post by Arne Vajhøj

Post by Arne Vajhøj
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.

[Dave Froble]

Post by Arne Vajhøj

Post by Dave Froble

Post by Arne Vajhøj
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.

Post by Arne Vajhøj
print not 0%
does print -1.

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

[Arne Vajhøj]

Post by Dave Froble

Post by Arne Vajhøj

Post by Arne Vajhøj
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.

Post by Arne Vajhøj
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

[Chris Townley]

Post by Arne Vajhøj
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.

[Simon Clubley]

Post by Arne Vajhøj
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.

[Arne Vajhøj]

Post by Simon Clubley

Post by Arne Vajhøj
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

[Arne Vajhøj]

Post by Arne Vajhøj

Post by Simon Clubley

Post by Arne Vajhøj
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

[Dan Cross]

Post by Arne Vajhøj

Post by Arne Vajhøj

Post by Simon Clubley

Post by Arne Vajhøj
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
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.

- Dan C.

[Simon Clubley]

Post by Dan Cross
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.
http://youtu.be/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.

[John Dallman]

Post by Simon Clubley
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

[Lawrence D'Oliveiro]

Post by John Dallman
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?

[Dan Cross]

Post by Simon Clubley

Post by Dan Cross
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.
http://youtu.be/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.

Post by Simon Clubley
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.

[Arne Vajhøj]

Post by Simon Clubley

Post by Dan Cross
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.
http://youtu.be/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. :-(

JavaScript has had a huge market share in presentation layer
in web applications for decades.

Either companies don't know how to profit maximize or
JavaScript is/was a good choice for this type
of code.

Small code bases, frequent releases and high user
tolerance for small ooopses favor a language like
JavaScript. Ada would not work well in this context
from a business perspective.

Code bases are not small anymore though. And TypeScript
has taken huge chunks of market share from
JavaScript in recent years.

Arne

[Arne Vajhøj]

Post by Arne Vajhøj

Post by Simon Clubley

Post by Dan Cross
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.
http://youtu.be/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. :-(

JavaScript has had a huge market share in presentation layer
in web applications for decades.
Either companies don't know how to profit maximize or
JavaScript is/was a good choice for this type
of code.
Small code bases, frequent releases and high user
tolerance for small ooopses favor a language like
JavaScript. Ada would not work well in this context
from a business perspective.
Code bases are not small anymore though. And TypeScript
has taken huge chunks of market share from
JavaScript in recent years.

If you really want Ada for this, then:

https://blog.adacore.com/use-of-gnat-llvm-to-translate-ada-applications-to-webassembly

:-)

Arne

[Dan Cross]

Post by Arne Vajhøj

Post by Simon Clubley

Post by Dan Cross
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.
http://youtu.be/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. :-(

JavaScript has had a huge market share in presentation layer
in web applications for decades.
Either companies don't know how to profit maximize or
JavaScript is/was a good choice for this type
of code.

Server side Javascript does not run on the browser.

Post by Arne Vajhøj
Small code bases, frequent releases and high user
tolerance for small ooopses favor a language like
JavaScript. Ada would not work well in this context
from a business perspective.
Code bases are not small anymore though. And TypeScript
has taken huge chunks of market share from
JavaScript in recent years.

Typescript is a better language. JavaScript should
have been better than it was, but that shippe has sailed,
and the story has been told many times: it was ten days
from conception to ship, and the consequent lack of
polish shows.

- Dan C.

[Arne Vajhøj]

Post by Dan Cross

Post by Arne Vajhøj

Post by Simon Clubley

Post by Dan Cross
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.
http://youtu.be/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. :-(

JavaScript has had a huge market share in presentation layer
in web applications for decades.
Either companies don't know how to profit maximize or
JavaScript is/was a good choice for this type
of code.

Server side Javascript does not run on the browser.

Post by Arne Vajhøj
Small code bases, frequent releases and high user
tolerance for small ooopses favor a language like
JavaScript. Ada would not work well in this context
from a business perspective.
Code bases are not small anymore though. And TypeScript
has taken huge chunks of market share from
JavaScript in recent years.

Typescript is a better language. JavaScript should
have been better than it was, but that shippe has sailed,
and the story has been told many times: it was ten days
from conception to ship, and the consequent lack of
polish shows.

If JavaScript was unique in the web frontend world
for lack of type safety, then the lack of type safety
could be due to its history.

But it is not unique. Other popular languages like
PHP and Python also has a relaxed approach to types.
Past popular languages like Perl and VBS same.

Web frontend is not like backend or embedded.

Arne

[Dan Cross]

Post by Arne Vajhøj

Post by Dan Cross

Post by Arne Vajhøj

Post by Simon Clubley

Post by Dan Cross
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.
http://youtu.be/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. :-(

JavaScript has had a huge market share in presentation layer
in web applications for decades.
Either companies don't know how to profit maximize or
JavaScript is/was a good choice for this type
of code.

Server side Javascript does not run on the browser.

Post by Arne Vajhøj
Small code bases, frequent releases and high user
tolerance for small ooopses favor a language like
JavaScript. Ada would not work well in this context
from a business perspective.
Code bases are not small anymore though. And TypeScript
has taken huge chunks of market share from
JavaScript in recent years.

Typescript is a better language. JavaScript should
have been better than it was, but that shippe has sailed,
and the story has been told many times: it was ten days
from conception to ship, and the consequent lack of
polish shows.

If JavaScript was unique in the web frontend world
for lack of type safety, then the lack of type safety
could be due to its history.

I didn't say anything about types, other than that TypeScript is
a better language than JavaScript. TypeScript is a better
language; typing is of course part of that, but not the only
part.

Post by Arne Vajhøj
But it is not unique. Other popular languages like
PHP and Python also has a relaxed approach to types.
Past popular languages like Perl and VBS same.
Web frontend is not like backend or embedded.

Non-sequitor: none of this has to do with why JavaScript is a
poor language.

PHP, by the way, is a horrible langauge; worse than JavaScript.
https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

None of this is to say that these things are not _useful_;
they undeniably are. That doesn't mean that they are _good_.

- Dan C.

[Lawrence D'Oliveiro]

If JavaScript was unique in the web frontend world for lack of type
safety, then the lack of type safety could be due to its history.
Other popular languages like PHP and Python also has a relaxed
approach to types.

Worth being clear what we’re talking about. None of these languages is
type-unsafe in the way that C, for example, allows free typecasting
between unrelated types, and in particular between pointers to unrelated
types. They are all dynamic languages, and every value that a variable can
hold does have an explicit type, and conversions between types follow
well-founded semantic rules.

However, JavaScript and PHP have a laissez-faire attitude to equivalences
with strings, and will happily autoconvert between strings and non-string
types in various situations, often leading to surprising results. This is
why both those languages have the “===” comparison operator as a stricter
form of “==” which says “turn off these string-nonstring autoconversions”.

Python never had this particular bit of brain damage. But it does still
have that common weakness with booleans. Which is a more manageable issue.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

If JavaScript was unique in the web frontend world for lack of type
safety, then the lack of type safety could be due to its history.
Other popular languages like PHP and Python also has a relaxed
approach to types.

Worth being clear what we’re talking about. None of these languages is
type-unsafe in the way that C, for example, allows free typecasting
between unrelated types, and in particular between pointers to unrelated
types. They are all dynamic languages, and every value that a variable can
hold does have an explicit type, and conversions between types follow
well-founded semantic rules.
However, JavaScript and PHP have a laissez-faire attitude to equivalences
with strings, and will happily autoconvert between strings and non-string
types in various situations, often leading to surprising results. This is
why both those languages have the “===” comparison operator as a stricter
form of “==” which says “turn off these string-nonstring autoconversions”.
Python never had this particular bit of brain damage. But it does still
have that common weakness with booleans. Which is a more manageable issue.

There are different conventions.

$ type cmp.php
<?php

function test($a, $b) {
if($a == $b) {
echo "true ";
} else {
echo "false ";
}
if($a === $b) {
echo "true\r\n";
} else {
echo "false\r\n";
}
}

test(0, 0);
test(0, 0.0);
test(0, '0');
test(0, 'X');
test(0, False);
test(0, null);

?>
$ php cmp.php
true true
true false
true false
false false
true false
true false
$ type cmp.py
def test(a, b):
if a == b:
print('true')
else:
print('false')

test(0, 0)
test(0, 0.0)
test(0, '0')
test(0, 'X')
test(0, False)
test(0, None)

$ python cmp.py
true
true
false
false
true
false
$ type Cmp.groovy
def test(a, b) {
if(a == b) {
println("true")
} else {
println("false")
}
}

test(0, 0)
test(0, 0.0)
test(0, "0")
test(0, "X")
test(0, false)
test(0, null)

$ groovy Cmp.groovy
true
true
false
false
false
false
$ type Cmp.java
public class Cmp {
private static void test(Object a, Object b) {
if(a.equals(b)) {
System.out.println("true");
} else {
System.out.println("false");
}
}
public static void main(String[] args) {
test(0, 0);
test(0, 0.0);
test(0, "0");
test(0, "X");
test(0, false);
test(0, null);
}
}
$ javac Cmp.java
$ java Cmp
true
false
false
false
false
false

Arne

[Lawrence D'Oliveiro]

Small code bases, frequent releases and high user tolerance for small
ooopses favor a language like JavaScript. Ada would not work well in
this context from a business perspective.

JavaScript is also a dynamic language, unlike Ada. Maybe not as dynamic as
Python, but still lets you do a lot in quite compact code.

I’m not sure I agree with the “tolerance for small ooopses”. There is a
thing called “use strict”, which helps catch common JavaScript errors. It
is even enforced in new-style modules.

Code bases are not small anymore though. And TypeScript has taken huge
chunks of market share from JavaScript in recent years.

TypeScript is just an attempt to add static typing to JavaScript. Maybe it
works for native-side code bases (i.e. not in a browser sandbox). But then
you pair it with Electron as your “GUI toolkit”, and you wonder why
Microsoft’s Visual Studio Code is such a huge download for such little
functionality ...

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Small code bases, frequent releases and high user tolerance for small
ooopses favor a language like JavaScript. Ada would not work well in
this context from a business perspective.

JavaScript is also a dynamic language, unlike Ada. Maybe not as dynamic as
Python, but still lets you do a lot in quite compact code.
I’m not sure I agree with the “tolerance for small ooopses”. There is a
thing called “use strict”, which helps catch common JavaScript errors. It
is even enforced in new-style modules.

If a web page gives an error, then users try to ignore it, try
with another browser and worst case just try again next day - and
nobody is really surprised. If airplane control software has an
error that cause a crash and kill hundreds of people, then it
makes world wide headlines.

Post by Lawrence D'Oliveiro

Code bases are not small anymore though. And TypeScript has taken huge
chunks of market share from JavaScript in recent years.

TypeScript is just an attempt to add static typing to JavaScript. Maybe it
works for native-side code bases (i.e. not in a browser sandbox).

I don't think the word *just* in "just an attempt to add static
typing" is a fair description.

It does add optional static typing, but that enables a lot
of things that impact how code is written: different way
to do OO, generics, enum etc.. It is a significant change.

Arne

[Lawrence D'Oliveiro]

Post by Arne Vajhøj
$ type bool.py
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/>

[Dave Froble]

Post by Simon Clubley

Post by Arne Vajhøj
declare integer const

ant TRUE = -1

Post by Simon Clubley

Post by Arne Vajhøj
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.

[Simon Clubley]

Post by Arne Vajhøj

Post by Simon Clubley

Post by Arne Vajhøj
declare integer const

ant TRUE = -1

Post by Simon Clubley

Post by Arne Vajhøj
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...

[Lawrence D'Oliveiro]

Post by Arne Vajhøj
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.