What could they have done better with the 99/4a?

[wierd_w]

I question how this could become a standard behavior.

 

It's in the same category of "nope" as assuming a null value variable's contents is equal to 0.  You are not actually asking if the value is true or false. You are literally asking if X exists, according to formal logic.

 

"The computer lets me do it" is not sufficient grounds for me. I will personally never use this kind of convention.

[apersson850]

That's up to you, of course.

 

Would you also write

IF TRUE=TRUE THEN

instead of the more obvious

IF TRUE THEN

when you need to create something that runs forever?

 

To me, the first one seems much more stupid than the second.

In languages with strong typing, like Pascal, you can only do

repeat

   xxx

until done;

assuming done is declared as a boolean, of course. But since BASIC usually can't tell the difference between a number and a boolean, that's what you get. If you type in

A=6

PRINT A=7

then the printed result is 0.

PRINT A<10 

will give you the result -1.

So the fact that all logical statements evaluate to a number, and then that number is tested, implies that testing only a number is equally valid. This is not any odd characteristic, it's a logical extension of how the system works.

 

But as you write, you can't assume that "null" is zero. In a Pascal system, there's a system constant for "nil". It's usually zero, but to be sure things work you have to test if pointer=nil then.

The danger with using this syntax in TI BASIC is this:

A = 0 now A is false

B = -1 now B is true

C = 1 now C is true too

A = NOT A this works, A is now true

B = NOT B this works, B is not false

C = NOT C this doesn't work, C is still true, because the two's complement of 1 isn't zero.

 

Since Pascal separates boolean variables from doing bitwise logical manipulations of integers completely, this is not an issue there.

Edited June 14, 2020 by apersson850

[wierd_w]

I wouldn't use a reserved keyword as a variable name.

 

For the sake of completeness though, I would probably use a while loop for that.

 

ImStillRunning=TRUE

WHILE ImStillRunning=TRUE

[Do stuff in here until the computer halts for some reason]

WEND

 

Or something similar. 

Edited June 14, 2020 by wierd_w

[apersson850]

It isn't a variable name, it is a reserved word. Which version would you use?

[wierd_w]

I answered.  I would likely use a while loop for that, not an unescapable IF statement, and gave an example.

 

Using TRUE in the manner you suggest, (An immutable constant TRUE being evaluated at all is tautologically silly), is something I would not even consider doing, despite it being obviously a true condition. 

 

It's about as absurd as using

 

IF 1=1 then

{dostuff}

ENDIF

 

If I saw it in a program, I would think the programmer was a pretentious douche who thinks his code can never encounter an unexpected condition, and feels his code should always, unequivocally, and without question, should always be run.

 

 

NOW--  Why you SHOULD NOT treat the "IF X THEN" statement as an evaluation on the CONTENT of the variable--

 

It can exist a condition where a variable exists, but has a null value, even in basic.  You can totally define X="". 

There is no clean case to ask the computer "Has X been declared before?", *OTHER* than asking it, literally "X?", such as in "IF X". 

 

It is not a question of "which do I find more aesthetically pleasing."  It is a question of "Doing it that way makes it impossible to ask a different, perfectly useful question."

 

[apersson850]

In a program that runs a couple of concurrent processes, then let them do the work, you could perfectly well have

 

start(processA);
start(processB);

 

while true do;

 

That's what I would write. Not end it with while true=true do; The last statement prevents the main program from stopping, and then implicitly killing the spawned processes.

 

In this kind of BASIC we have here, you can't write X="". You must use X$="". And string variables can't be used "stand alone" in an IF statement.

 

In many BASIC versions, and especially for computers like the 99/4A, you don't declare variables at all. They are put into the symbol table as soon as they are encountered, or during a pre-scan. Which means that as soon as you write IF X you have mentioned X, and it's implicitly declared. In a language like Pascal, writing if x when x has not been declared will be trapped already by the compiler, so it will never get a chance to execute. The question if a variable is declared seems redundant, at least as far as the 99/4A is concerned.

Edited June 14, 2020 by apersson850

[RXB]

1 hour ago, wierd_w said:

I question how this could become a standard behavior.

 

It's in the same category of "nope" as assuming a null value variable's contents is equal to 0.  You are not actually asking if the value is true or false. You are literally asking if X exists, according to formal logic.

 

"The computer lets me do it" is not sufficient grounds for me. I will personally never use this kind of convention.

No it just asks: if X is NOT ZERO then goto line number.

What do you not understand about this?

 

Want to see this in GPL:

CZ @>8300

BS YESGOHERE

BR NOGOHERE

 

In XB same this is IF X THEN LINE#

 

 

 

 

Edited June 14, 2020 by RXB

[wierd_w]

I understand that it is used that way, yes.

 

My statement is that this is LOGICALLY IMPROPER, and SHOULD NOT BE DONE

As for why you would want to check if a variable has been declared or not?

 

Suppose you have a subroutine, that declares a variable used to mark a process tree in some way. Perhaps we are marking that it executed abnormally or something.  We are not going to evaluate its content. EVER. We only want to know if it got declared.  We do not care where in the recusion/subroutine call chain it got defined, only that it did. There can be reasons to do it this way (such as changing how memory is laid out, by the addition of the designator) vs overtly using a boolean, and then checking its value.

 

At the end of the processing, we check to see if the variable was ever defined. If it was, we know that the subprocess encountered an unusual condition, but was able to continue. 

 

Alternatively, we have a block of code that wants to know if a variable exists or not. (we will assume we cant use arrays.) It is intended to be called recursively, but to NOT smash its owns values.  To that effect, it has some degree of tolerance to check if a value has been set previously or not, and based on that, know how many levels deep its recursion is.

 

A third case exists for more modern basics, like VB that does object oriented structuring.  It is possible to have an object child with no value, but an object child index, that will throw off all your subsequent operations if you do not check for the existence of the child object first, and then account for it.  You do not want to create this child object upon check; Only check to see if it exists or not, so that your child index numbers will always be right.

 

 

LOGICALLY--  When you ask a question like "IF X", it is in a context like this:

 

I have a box.  It has length, and width.  It does not have any conception of depth.

If you ask me "If its depth is...", it is an absurd condition. No value for depth exists, nor can it. The answer is "no."  because "There is no depth." This answer is completely unrelated to any value Depth might have, should it exist.

Edited June 14, 2020 by wierd_w

[RXB]

14 minutes ago, wierd_w said:

I understand that it is used that way, yes.

 

My statement is that this is LOGICALLY IMPROPER, and SHOULD NOT BE DONE

As for why you would want to check if a variable has been declared or not?

 

Suppose you have a subroutine, that declares a variable used to mark a process tree in some way. Perhaps we are marking that it executed abnormally or something.  We are not going to evaluate its content. EVER. We only want to know if it got declared.  We do not care where in the recusion/subroutine call chain it got defined, only that it did. There can be reasons to do it this way (such as changing how memory is laid out, by the addition of the designator) vs overtly using a boolean, and then checking its value.

 

At the end of the processing, we check to see if the variable was ever defined. If it was, we know that the subprocess encountered an unusual condition, but was able to continue. 

 

 

LOGICALLY--  When you ask a question like "IF X", it is in a context like this:

 

I have a box.  It has length, and width.  It does not have any conception of depth.

If you ask me "If its depth is...", it is an absurd condition. No value for depth exists, nor can it. The answer is "no."  because "There is no depth." This answer is completely unrelated to any value Depth might have, should it exist.

NO ONE IS CHECKING IF THAT VARIABLE IS USED OR NOT, it is checking if for NON ZERO VALUE, it is used as a FLAG VARIABLE. (zero or non zero)

We do the same thing in Assembly and GPL and C all the time.

You are purposely adding insane amounts of complications to a easy to understand code.

Even a child can see this works, why you want to make it look so complicated that no one unless has a degree can use it is pretty silly.

Basically you are just being  argumentative and refuse to see people use something for the last 30 years.

Can you change history too ?

Edited June 14, 2020 by RXB

[wierd_w]

RXB:

 

There are 2 ways to evaluate that with BASIC. One is by using an explicit operator, and one is by doing it the wrong and stupid way, which you keep defending.

 

If you permit the wrong and stupid way, you remove the POTENTIAL to do the kind of check I stated.  FOR PURELY AESTHETIC REASONS.

 

 

To wit-

 

If I *WANTED* do do that kind of check, how could I do it? (Since you removed the obvious syntax, for purely aesthetic reasons, as an alias for the more proper syntax of a completely unrelated query.)

Edited June 14, 2020 by wierd_w

[Casey]

1 hour ago, wierd_w said:

I question how this could become a standard behavior.

 

It's in the same category of "nope" as assuming a null value variable's contents is equal to 0.  You are not actually asking if the value is true or false. You are literally asking if X exists, according to formal logic.

 

"The computer lets me do it" is not sufficient grounds for me. I will personally never use this kind of convention.

You may never do it, but I would argue that 

100 IF EOF(1) THEN CLOSE #1 

or

100 IF NOT EOF(1) THEN INPUT #1:A$

makes more sense logically than:

100 IF EOF(1)=-1 THEN CLOSE #1

 

(The resequence thing where you or someone wants the computer to magically add direct statements to a program is a whole separate bit of nonsense.)

[RXB]

4 minutes ago, wierd_w said:

RXB:

 

There are 2 ways to evaluate that with BASIC. One is by using an explicit operator, and one is by doing it the wrong and stupid way, which you keep defending.

 

If you permit the wrong and stupid way, you remove the POTENTIAL to do the kind of check I stated.  FOR PURELY AESTHETIC REASONS.

 

 

To wit-

 

If I *WANTED* do do that kind of check, how could I do it? (Since you removed the obvious syntax, for purely aesthetic reasons, as an alias for the more proper syntax of a completely unrelated query.)

So it is stupid because you say so?

Hmm really we have been using the TI for 30 years and we are all stupid because you say so....

 

Here is a Clue for you: BASIC or XB is not Assembly Pascal or C or Quick Basic or MS Basic.

It has been around for over 30 years, so your view of this is pretty much useless in respect to history and number of programs written using it.

 

This is similar to a Word NAZI on people using Slang. Does not matter how you feel it is being used like or not, and will continue to be used.

Both work the same way, your opinion is not going to change anything. FACT!

[wierd_w]

I would not pretend that I know what the actual number value written for a TRUE statement is.  Basic programs are meant to be portable. That is how you break that portability.

 

Instead, I would use

 

100 IF EOF(1)=TRUE THEN CLOSE #1

 

That puts the decision on what should be actually encoded there squarely in the hands of the native interpeter, and not the supposition of the programmer.

[Casey]

4 hours ago, wierd_w said:

He means, that if you have a situation like this

 

10 PRINT "This is a line. Yay."
PRINT "This line intentionally has no line ID!"

20 PRINT "This is the next actually numbered line!"

 

 

The interpreter should do this:

 

10 PRINT "This is a line. Yay."
11 PRINT "This line intentionally has no line ID!"

20 PRINT "This is the next actually numbered line!"

 

and not this

 

10 PRINT "This is a line. Yay."
32767 PRINT "This line intentionally has no line ID!"

20 PRINT "This is the next actually numbered line!"

No, this is not at all what he means.

 

What he means is:

 

>100 IF A=1 THEN 200

>110 END

>RESEQUENCE

>LIST

 100 IF A=1 THEN 32767

 110 END

 

He isn’t asking the interpreter to magically turn direct statements into program lines.  He’s asking for something else.  (I’m not sure what the solution is to this - it’s hard for an interpreter to know what you intended, but maybe a message in the output of RESEQUENCE?)

[wierd_w]

1 minute ago, RXB said:

So it is stupid because you say so?

Hmm really we have been using the TI for 30 years and we are all stupid because you say so....

 

Here is a Clue for you: BASIC or XB is not Assembly Pascal or C or Quick Basic or MS Basic.

It has been around for over 30 years, so your view of this is pretty much useless in respect to history and number of programs written using it.

 

This is similar to a Word NAZI on people using Slang. Does not matter how you feel it is being used like or not, and will continue to be used.

Both work the same way, your opinion is not going to change anything. FACT!

It is stupid, because it was done for aesthetic reasons, and removes potential value to do it.

 

The argument is not "Was it done" and "Does the system do it this way." 

 

NO.

 

It is "IT should NOT have done it that way, and this is why."

 

to which your response has been a robotic "It does it that way."

 

We are arguing past each other it seems.  This is why I asked you (rather pointedly), that if I had WANTED to do that kind of check, how could I do it?  (knowing full well you cannot easily do it, because the obvious syntax for it has been subsumed as an alias)

[RXB]

2 minutes ago, Casey said:

No, this is not at all what he means.

 

What he means is:

 

>100 IF A=1 THEN 200

>110 END

>RESEQUENCE

>LIST

 100 IF A=1 THEN 32767

 110 END

 

He isn’t asking the interpreter to magically turn direct statements into program lines.  He’s asking for something else.  (I’m not sure what the solution is to this - it’s hard for an interpreter to know what you intended, but maybe a message in the output of RESEQUENCE?)

Just tried to do this in RXB and hmm that does not happen.

line 100 IF A=1 THEN 200  does not change

Even if you do this

1 IF A=1 THEN 200

2 END

RES

LIST

100 A=1 THEN 200

110 END

 

NO CHANGE AT ALL!

 

[RXB]

2 minutes ago, wierd_w said:

It is stupid, because it was done for aesthetic reasons, and removes potential value to do it.

 

The argument is not "Was it done" and "Does the system do it this way." 

 

NO.

 

It is "IT should NOT have done it that way, and this is why."

 

to which your response has been a robotic "It does it that way."

 

We are arguing past each other it seems.  This is why I asked you (rather pointedly), that if I had WANTED to do that kind of check, how could I do it?  (knowing full well you cannot easily do it, because the obvious syntax for it has been subsumed as an alias)

Dude you are deliberately making something which XB is supposed to be much to complicated to understand. Why and for what reason?

Basic and XB are designed to be easy to use and understand. 

This is not FORTH where you cow town to the processor and stack instead of being for the USER!

C has the same issue it is not made for easy to read code as even Dennis Ritche said this: "In C you can write code even I can not tell what it is doing."

 

[Casey]

4 minutes ago, RXB said:

Just tried to do this in RXB and hmm that does not happen.

line 100 IF A=1 THEN 200  does not change

Even if you do this

1 IF A=1 THEN 200

2 END

RES

LIST

100 A=1 THEN 200

110 END

 

NO CHANGE AT ALL!

 

Interesting.  TI BASIC and TI Extended BASIC both change the reference to 32767, so you did make it better

[wierd_w]

As stated-- There can be legitimate reasons to make that kind of check.

 

That is why it needs to be preserved.

[RXB]

1 minute ago, Casey said:

Interesting.  TI BASIC and TI Extended BASIC both change the reference to 32767, so you did make it better

Actually yes, but not me Miller Graphics did that when they added more options to the Editor in XB.

I use Miller Graphics XB mods as my base of RXB.

[Tursi]

1 hour ago, apersson850 said:

The IF statement evaluates an expression. If it comes out to -1 (in many cases, as it's the two-complement of zero), it's true. Some systems use 1 and 0, not -1 and 0.

True, except that in the end the statement looks for 0 or not 0. (-1 or 1 is the value used for true, but not tested against, only zero).

 

And yes, this is completely standard behavior in programming languages. The condition is first evaluated down to a value, and then the result is tested.

 

[wierd_w]

Again, since the actual value written there might be something other than the programmer anticipates (EG, program written for say, IBM Basic-- ported (more or less) to TI Basic), it is just better practice to use the internal constant, rather than pretend to know what that constant's actual value *IS*.

 

That way it is less bother to somebody who wants to run the program on another machine, with a different interpreter, that does things differently.  The constant can always be relied upon. The actual value that constant represents not so much. (For all you know, the basic interpreter down the line is super economical, and uses a single bit out of a bitfield it reserves for booleans, and not the whole byte!) Better to just evaluate against whatever "TRUE" constant the interpreter provides, and let it figure it out.

Edited June 14, 2020 by wierd_w

[HOME AUTOMATION]

You've all been goin' at it again ...without me!

 

But You're all wrong...

 

In my theory anyway, any expression containing more than two postulates ...is OVERLY-COMPLEX and should be avoided, in favor of doing it the lengthy and therefore more manly way!

 

 

Edited June 14, 2020 by HOME AUTOMATION

[RXB]

10 hours ago, wierd_w said:

As stated-- There can be legitimate reasons to make that kind of check.

 

That is why it needs to be preserved.

What is preventing you from doing that way?

Checking for a non zero is stopping you? 

You can add or subtract values to the check with NOT,  OR,  AND,  NOR,  thus what is your problem here?

[apersson850]

10 hours ago, wierd_w said:

Again, since the actual value written there might be something other than the programmer anticipates (EG, program written for say, IBM Basic-- ported (more or less) to TI Basic), it is just better practice to use the internal constant, rather than pretend to know what that constant's actual value *IS*.

No, that's neither the case nor the problem.

What happens when you enter IF X THEN is that the computer executes an implicit IF X=TRUE THEN. That's already taken care of. When you write IF X<5 THEN the computer actually evaluates IF (x<5)=TRUE THEN for you. That's why you (probably) do not write the code IF (X<5)=TRUE THEN in your programs. The comparison against TRUE is implied.

Thus this i as portable as it gets.

 

What is not portable is assuming that these two have specific numeric values. That's mainly a problem in BASIC, where there are no specific boolean values. That's why

IF X<5 THEN P=P+80

can be replaced by

P=P-80*(X<5)

in TI Extended BASIC, but it may fail on a different machine. That's also why both A and NOT A can be true at the same time, if A contains a value that's neither the one used for true nor for false in this particular BASIC.

 

As stated before, testing if a value exists is pointless in many languages, as it does, by definition, exist as soon as you mention it. Or you get an error for mentioning it, before it's declared.

Pascal can create variables on the fly, but in doing so, you have to have a pointer refering to the variable. Writing code like if pointer then, where you want to know if the pointer is referring to something, never works. Neither does just writing if pointer<>nil then, since a variable in Pascal can have any value when the program starts. You have to explicitly set pointer := nil when your program starts. If a new(pointer) is then executed, the pointer variable will change to something that's not nil. Note that in this case there's never any question about if pointer exists. What may change is if pointer^ exists or not.

But again, whether such a variable has been created or not, i.e. if pointer is nil or not, it still a logical tests in the end. What you are actually asking is if (pointer<>nil)=true then. But you don't write like that, since it's assumed that the if statements compare the result to true, whatever true may be represented with in a particular machine.

 

As you can see, this behavior is the only consistent one. Allowing for IF X THEN as a test for if X has been used before would be a deviation from logic and consistency. It should be handled by constructs like IF EXISTS(X) THEN or if x.exists then. Or, as you prefer, IF EXISTS(X)=TRUE THEN or if x.exists=true then.