Waverly, I can't speak for the FBtoC team, but for my money, FB has always been thus, and I see no reason for a change. Yes, I've made a similar error once or twice myself, but it's a simple matter of debugging. On Nov 11, 2009, at 9:41 AM, Edwards, Waverly wrote: > Since the equal sign is right associative, it really should fail > unless the language allows multiple assignments, which FB does not. I don't understand your statement about = being "right associative." A single = always invokes a comparison UNLESS it follows a var or _constant at the beginning of a statement, in which case it becomes an assignment. > At minimum, this should be a warning. > > _delimiterIsComma = _currentDelimiter = _"," > > equivalent to: because of right associativity in languages such as > FB where multiple assignments are not allowed > > > _delimiterIsComma == ( _currentDelimiter = _"," ) vs This will not compile, because a statement cannot start with a comparison > _delimiterIsComma = ( _currentDelimiter == _"," ) This will compile the same as _delimiterIsComma = _currentDelimiter = _"," > equivalent to: where languages such as C and Java where multiple > assignments are allowed > > _delimiterIsComma = _currentDelimiter = _"," > > the _delimiterIsComma and currentDelimiter would be assigned the > value of _"," > > You make a great point but at minimum there should be a warning of > an unintended assignment. In FB syntax, there IS no unintended assignment, just an assignment and a value returned by a comparison, so what should the warning be? What rule should be used to apply it? I'm glad you were able to find your bug. That can be a tricky one. e-e =J= a y " > > -----Original Message----- > From: Jay Reeve [mailto:jayreeve@...] > Sent: Wednesday, November 11, 2009 10:28 AM > To: futurebasic@... > Subject: Re: [FB] FBToC: bad enumeration > > Waverly, > > Well, I certainly wouldn't want it to be illegal. Nor would I know > what kind of rule to apply to eliminate it. Here's an arbitrary > example in which it might be used: > > _currentDelimiter = _"," //in a Settings file > ' > '... > ' > _delimiterIsComma = _currentDelimiter = _"," //in a code file > ' > '... > ' > LONG IF _delimiterIsComma //in a FN > '... > XELSE > > The only way I can see to prevent an error like yours would be to > require == instead of = for all equality comparisons. I suspect that > might break a majority of existing code, so will probably never > happen. > > e-e > =J= a y > " > > On Nov 11, 2009, at 9:11 AM, Edwards, Waverly wrote: > >> Your code is setting the constant _apostrophe to the value of the >> comparison: >> ( _"'" == 39 ) >> which evaluates to _zTrue or -1 >> << >> >> Oh, I get it now. Because it evaluated to a static value, it was >> allowed. >> Hmmm, I don't know about that behavior. Its legal but should it be? >> >> >> W. >> >> >> -----Original Message----- >> From: Jay Reeve [mailto:jayreeve@...] >> Sent: Wednesday, November 11, 2009 12:40 AM >> To: futurebasic@... >> Subject: Re: [FB] FBToC: bad enumeration >> >> Waverly, >> >> Your code is setting the constant _apostrophe to the value of the >> comparison: >> ( _"'" == 39 ) >> which evaluates to _zTrue or -1 >> >> It's perfectly good code, just not what you intended. Remove either >> the = _"'" or the = 39 and it should work as expected. >> >> e-e >> =J= a y >> " >> >> On Nov 10, 2009, at 5:51 PM, Edwards, Waverly wrote: >> >>> >>> I had the strangest problem. In my program I kept attempting to >>> test a variable to see if it as equal to _apostrophe >>> I knew it was equal but it never tested positive. I went back to >>> my declarations to ensure that _apostrophe was >>> equal to ASCII value 39. After a fair amount of head scratching I >>> noticed that my declaration was incorrect. This >>> is exactly the line that I had in my program. >>> >>> _apostrophe = _"'" = 39// ASCII TABLE (39), an >>> apostrophe mark >>> >>> I didnt get a warning, the program compiled just fine and >>> everything was working except for the variable test. >>> >>> ex: if ( var == _apostrophe ) then stop "_apostrophe == _zTrue " >>> >>> >>> W. >>> -- >>> To unsubscribe, send ANY message to: futurebasic- >>> unsubscribe@... >>> >>> >> >> -- >> To unsubscribe, send ANY message to: futurebasic- >> unsubscribe@... >> >> -- >> To unsubscribe, send ANY message to: futurebasic- >> unsubscribe@... >> >> > > -- > To unsubscribe, send ANY message to: futurebasic- > unsubscribe@... > > -- > To unsubscribe, send ANY message to: futurebasic- > unsubscribe@... > >