Why do IF statements need expressions and not work on simple values?

[hwholmes]

Pardon me if this has been discussed before or is on the wish list (a quick search was not good enough for me to find one.)

Most other languages with which I am familiar (including BASICs) allow statements such as:
IF {variable/constant/expression} then ... do something etc. but PICAXE Basic seems to require an expression.

A false would simply be a ZERO (or empty string "") and true is anything else.

If I understand correctly; if a false preceeds an AND the interpreter can quit with the false behavior otherwise continue evaluation. Similarly a true is followed by an OR will quit with the TRUE behavior otherwise continue. Finally if the expression ends the final value determines the behavior.

What I don't get is why a single value can't be parsed as end of expression.

Yes, there may even be times when I want to have the IF expressed programaticaly but only want to test one condition and therefor use a constant as the temporary argument.

Bert

 

[inglewoodpete]

I'm not sure what you mean. A PICAXE is limited to simple data comparisons.

Valid "If" statements:
If b0 = 1 Then
If b0 = "A" Then
If b0 = b2 Then
If @ptr = "B" Then
If pinC.1 = 0 Then
If b0 = 1 And pinC.1 = 0 Then

But the PICAXE can't resolve calculations in an "If" statement:
If b0 = b1 + 3 Then

Can you post an example of the code that is causing your probelm?

 

[hwholmes]

I'm not sure what you mean. A PICAXE is limited to simple data comparisons.
.....
Can you post an example of the code that is causing your probelm?

Thanks for the reply but I think you misinterpreted my question.

First this is not a problem but just a minor inconvenience and I am not interested in making an assignment within an IF.

Actually you expressed my concern exactly. However I see it as a minimum limit in that "IF" REQUIREs a comparison (expression) and can't simply evaluate the value as true or false?

I would expect "IF Bit0 then .... " to be sufficiently true or false without comparing it to something else.

"If Bit0 = 1" and "If Bit0" should be equivalent and are in most other languages I have studied.
Similarly "If Bit0 = 0" and "If Not Bit0" should be equivalent.

Also "If B0 then...." would evaluate that B0 is not ZERO.

It might be even more usefull evaluating inputs such as "IF PinC.2 then...". The input is already true or false. Why do I have to ask?

Bert

 

[inglewoodpete]

Yep. I understand now. I'm with you on that one.

I'll add a couple of suggestions to the PE Vers.6 wishlist. They may have already been suggested.

 

[MartinM57]

It might be even more usefull evaluating inputs such as "IF PinC.2 then...". The input is already true or false. Why do I have to ask

not really IMHO...pinc.2 is either 0 or 1 (as in traditional low/high). You have used the C type interpretation of 0 = false, everything else = true, to make that mental leap.

Remember this is PICAXE BASIC, not C and I would vote to leave it as is - it enforces clear thinking and clear code. Many seasoned programmers still get caught out with the 'everything else is true, not just 1' paradigm, and I'm aware of many C programming standards that insist that IF conditions are always comparisons for initial clarity and subsequent maintenance.

IMHO

 

[g6ejd]

I think the interpretation of the expression could useful deduce a logical outcome, so IF PortC.2 THEN was established at run time against the standard 1 = True, then process the statement. All the PE would need to do is add the P-Code IF 'PortC.2 = 1' THEN it would be a nice convenience update.

 

[hwholmes]

not really IMHO...pinc.2 is either 0 or 1 (as in traditional low/high).

Martin: I agree and an evaluation is also either true or false (1 or 0), it seems to me to be the same.

You have used the C type interpretation of 0 = false, everything else = true, to make that mental leap. Remember this is PICAXE BASIC, not C and I would vote to leave it as is -

I generally prefer to stay as far from C and its clones as possible so I wouldn't know if that is how C works, but I have used several Tiny BASICs <TB> (and PicAxe Basic seems to be a larger version of a TB and they all allowed a ZERO value to be considered FALSE and a ONE (and usually any nonZero value, especially -1 or $FFFF...) to be considered TRUE.

it enforces clear thinking and clear code. Many seasoned programmers still get caught out with the 'everything else is true, not just 1' paradigm.

This I can fully agree with, I am generally a fan of clearly readable code. However when the average statement execution time is a quater of a millisecond at high frequency cliping off a little can make a difference. Yes I know what can happen when you AssUMe that it would be faster, some how the background code needed can use up or even exceed the anticipated savings.

As the title of my original post says I am asking WHY, there may be all kinds of reasons like that's the way the designers wanted it. Of course if it is possible for a future version to impliment this (with a speed benefit) I would probably use it. For my own personal use I don't find it unclear.

Bert

 

[John West]

I've got to stop reading these sorts of threads so early in the morning. They make my head hurt.

 

[inglewoodpete]

I've found they're OK when read with sunglasses.

 

[MartinM57]

We also don't know if IF pinC.2 = 1 THEN ... is detected by the PE and has a more efficient implementation than we think that say IF b0 = 10 THEN ... has

 

[boriz]

Generally, I'm with you. I like to use logic like that in my IF statements. I miss being able to do stuff like ... IF good and (whelks * bad) etc..

However, I would vote against adding that to Picaxe basic. The interpreter is slow enough as it is. Addition of features like this will bulk it out and slow it further. (See how the interpreter got slower for the M2 parts upgrade)

In fact, I would like to see things go the other way. Simplify the syntax to make it more machine-code friendly and run faster.

 

[inglewoodpete]

See how the interpreter got slower for the M2 parts upgrade.

I think that was because they added an extra bit to the tokens. (I've been known to be wrong, though)

 

[g6ejd]

Yes, I believe it would be easy to jump out of basic by saving the current stack and return address then calling some user supplied machine code then on return restoring the stack and carry on, the problem would be though maintaining the status of the interpreter and a guarantee of correct operation, as some customers would surely complain no matter how many disclaimers were made.

 

[boriz]

I think the problem would really be that it would be quite simple for user supplied machine code to PEEK and copy the whole firmware.

 

[Technical]

It's relatively simple for the compiler to simply automatically parse

if var then...
as
if var <> 0 then...

It makes no difference to the firmware or processing speed as the compiler just adds the '<>0' in the background, but if people would like it added we can add the idea to the wish list.

 

[Jakob2803]

Why do you need to use endif? How do you make the program do more than one line of code for the if-statement?

 

[MartinM57]

It would actually have to be

if var <> 0 then ...

...to make it consistent with other languages that allow similar constructs (and I wouldn't like to see an "if var then..." that was inconsistent with them) See, confusion already

I don't think I would vote for it....

 

[AllyCat]

How do you make the program do more than one line of code for the if-statement?

Hi Jakob,

Write multiple lines of assigments instead of a GOTO ! But I'm not sure if an ENDIF is (also) strictly essential if a GOTO is used.

Back onto the original topic, perhaps the "conditional" part could be optional rather as LET is optional (or did I read somewhere that occasionally the syntax requires it ?), so that the structure can explicit for beginners but "tidier" for seasoned programmers.

Personally, I don't find the mandatory condition too arduous, but do find the inability to write more complex expressions in IF statements to be frustrating. IMHO something like the following looks so much tidier than having to introduce an additional variable:

IF loopcount // 5 = 0 THEN SERTXD(CR,LF) ENDIF ; Format 5 values to a line

Cheers, Alan.

 

[g6ejd]

I think the problem would really be that it would be quite simple for user supplied machine code to PEEK and copy the whole firmware.

Of course, I had not thought of that aspect, if asked, that's why I would not include that capability too if it were me and my design...

Good spot.

 

[boriz]

I've been begging for an inline assembler for years. This is ultimately the reason given why we can't have one.

 

[Buzby]

Hi Boriz,

Yes, the inline assembler would give the user the ability to copy the firmware, then build their own PICAXE chips.

But to what end ?.

They might sell a few hundred, but without the No.1 feature available only to real PICAXE users they will soon fail.
( The other big thing you can do with assembler is 'brick your chip', imagine the support issues arising from that ! )

But, back to the original thread, I too would like 'If var then', where var evaluates to True for non-zero.
Also, I would like the True/False constants for 1 ( or maybe 65535 is better ) and 0.

Cheers,

Buzby

 

[BeanieBots]

Hi Boriz,
...I too would like 'If var then', where var evaluates to True for non-zero.
Also, I would like the True/False constants for 1 ...

It's already available!

symbol condition = b0
symbol True = 1

if condition = true then
endif

Personally, I prefer to have the deffinition of "true" under MY control. I might want to change my mind later about what is true!
Also, IMHO the above is far less ambiguous.

 

[Buzby]

Hi BeanieBots,

Yes, you have a good point about choosing your own version of True. ( A bit like a politician or a partisan historian. )

I had a software issue with two products, from the same major multinational company, which wouldn't work together because they each had a different version of 'True'.

So I take back my request for a fairly constant True.

Cheers,

Buzby

 

[Technical]

There is no intention to add predefined true/false, after all it is simply a symbol line at the top of the program for those who want to use it.

 

[boriz]

It's already available!

No it isn't. Your example still has an '=' sign and two arguments. The request is about a single argument with no comparison operator.

 

[hwholmes]

@Buzby Thanks for getting the discussion back on topic. I'm not sure what message g6ejd thought he/she was responding to talking about stacks and machine code but it surely put this discussion off track.

I can agree with almost all of the arguments about what is true and what is understandable but I don't see the objection to single argument, as such, (AssUMing) it didn't have a run time penalty and was preferably faster because it was "shorter"?) since the current version would still be there and could be emphasized/encouraged in the manuals. Single argument could even be totally ignored in the documentation to be left to be "discovered" by the savvy user.

Bert (the originator of the QUESTION.)

 

[chipwich]

Excellent thread. I think my request on this topic is slightly different than those already expressed. I'd like the ability parse something like "if const1=const2 then..." .

For instance:

symbol MODE_QUIET=0
symbol MODE_NORMAL=1
symbol MODE_VERBOSE=2
symbol TESTMODE=1

init:
	if TESTMODE=MODE_VERBOSE then 
		gosub printData
	endif

Right now, the workaround is to use a variable for the comparison, so the "if" statement looks like:

	b0=TESTMODE
	if b0=MODE_VERBOSE then 
		gosub printData
	endif

Not a huge issue, but the variable usage seems quite unnecessary and actually consumes extra memory.


In fact, since these conditional blocks can be determined entirely when syntax is checked, if the condition is false, then they can be removed entirely from the download. This would free up PICAXE memory, compared to the current handling.

 

[hwholmes]

..... I'd like the ability parse something like "if const1=const2 then..." ...

chipwich: I think we may already have what you are requesting. If I understand what you are looking for, those decisions can be made at compile time. Are you aware of the #IFDEF structure for writing having the compiler make the decisions about what to compile?

Example from manual2

#ifdef / #ifndef label
#else
#endif

Conditionally compile code depending on whether a label is defined (#ifdef) or
not defined (#ifndef).

Example: 
#define clock8
#ifdef clock8
   let b1 = 8
#else
   let b1 = 4
#endif

 

[chipwich]

chipwich: I think we may already have what you are requesting. If I understand what you are looking for, those decisions can be made at compile time. Are you aware of the #IFDEF structure for writing having the compiler make the decisions about what to compile?

Thanks for pointing this out, hwholmes. This is a C preprocessor directive. For simple boolean conditionals, this directive is fine. But if you want to go one step beyond a simple ifdef/ifndef, it's not quite enough. In my example, TESTMODE had multiple values. These are determinable at syntax checking time, so they can be handled by the preprocessor, and don't require any change to the PICAXE firmware.

Some preprocessor directives always felt like "hacks" to me (eg, #define, #ifdef, #ifndef). This is a good example of where we can accomplish the same preprocessor efficiency, while maintaining the formal syntax of the language. My observation is that as one moves toward more powerful object-oriented languages, it becomes more necessary to maintain consistent and fairly simple syntax. PICAXE basic isn't going OOP anytime soon, but I think it could still benefit from some modern CS learnings.

 

[hwholmes]

From your reply I think you understood what I suggested, but just in case here is my take on your code:

  '#Define MODE_QUIET              'comment out the invalid modes
  '#Define MODE_NORMAL
#Define MODE_VERBOSE        'keep only the one(s) that apply

init:
   #ifdef MODE_VERBOSE
        gosub printData                  ' This line will be compiled into your program.
   #endif