Why doesnt this work?

Local T:String
T = "h"
While Not T=Chr(34)
	Print "Made it"
	T=Chr(34)
Wend

It should print out "Made it" but it doesnt. Any ideas?

It only seems to do it with the quote character (tried using "~q" and such, and it does the same)

Hmm. I'm not sure why its not working as is but putting brackets around T=Chr(34) works. You should use "~q" now though.

Local T:String
While Not (T=Chr(34))
	Print "Made it"
	T=Chr(34)
Wend

It's the Not

"~q" doesnt work either

The problem is that Not has higher precedence than = so it is done first.

There is a table of operator precedence in the Expressions section of the Language Reference.

But then it isn't basic compadible....

It is a 'not' comparisson, standard basic true/false evaulation.

How can one 'expect' a program to operate a certain way if it doesn't follow a standard set of rules.

I posted a solution higher up.
You need to put brackets around the operations you want to perform before Not is applied.

as it was originally, you were effectively doing:

While (Not T) = Chr(34)

and since (Not T) will never = chr(34) it is never run.

I don't think there is any standard set of rules.

For example, C and Pascal both give their 'not' operators higher precedence than comparisons.

Actually, I have complained about And/Or having the same precedence. But nothing changed then so I wouldn't expect any changes now.

thanks for the 'workaround' there Perturbatio. I do appreciate it, however it still dissapoints me a bit.

The more I think the basic code of Blitz can port (for the most part) to blitzmax, the more I find I am mistaken and must re-write/re-learn how to program.

I agree there Floyd, however in C you can say if(d!=1) and it works.the () are requirements of the C language. Where with blitz I now have to encapsulate everything in () and hope I am correct as to the way it 'should' evaluate in refference to the way it 'actually' evaluates.

I have always encapsulated and/or clauses with () since in most basic languages they have the same precedence, however one would hope that in an evaluation the compiler would check for a preceeding expression before assuming it has completed the evaluation. One would hate it if you said a=5+5 and have the compiler merely return 5 to 'a' and syntax error the '+5'.

Perhaps we should be using the '==' instead :-(

Uh, what? I posted the answer first but oh well. Maybe you didnt undersand "brackets".

Not having higher precendence than a comparison makes no sense at all. This is what i thought at first was going on, but I disregarded it because I thought that blitz would say you cant compare an integer (result of a boolean) to an object.

<edit>Although, on second thought you should never have to use not like this. Just replace the = with <> and take out the not.

I understood brackets perfectly well, I must have over looked your post because of how small it was in comparrison to the two around it (my bad).



Yeah, I started using the <> just after making this thread. But what do you mean on never having to use not like this? I thought the evaluation was pretty straight forward.

Well, you never have to use not on a comparison because all the comparisons have inverses. (like > and <=, < and >=, = and <>)