Simple feature request regarding TRUE.

[Brian Alvarez]

 Hello Charles, I would like to request that just like indexbase, there was
a switch for TRUE to become 1 or -1 in Oxygen. Or maybe there is already?

 I am doing c++ compilations as well as BASIC compilations.

 When i compile c++ code in oxygen, i need the following to evaluate to 1:

Code: [Select]

byteVariable = (byteVariable = 0)
 But when compiling BASIC, i need it to evaluate to 255 (-1 overflows a byte).

 That simple.
Thanks.

[Charles Pegge]

True is a macro which can be redefined anywhere. Its initial value is 1.

def true -1

[Brian Alvarez]

It fails. Am i doing it wrong?

Code: [Select]

byte bt = 0

def true -1
   
bt = (bt = 0)

if bt = 255 then
    print "succeded."
else
    print "failed; bt = " bt
end if

[Brian Alvarez]

Maybe i didnt explain correctly.

I would like Oxygen to also follow this true definition when evaluating
statements like (bt = 0), so that it evaluates to -1 or 0 depending on what
true means.

[Mike Lobanovsky]

When i compile c++ code in oxygen, i need the following to evaluate to 1:

Code: [Select]

byteVariable = (byteVariable = 0)

You will never get a C++ compilation of this statement to evaluate to 1 because it is not a C++ evaluation but rather a compound assignment statement. The C++ parentheses are a scoping operator that always returns the result of operation in between them (i.e. always 0 in this particular case). Thus, the above statement can be reduced to just

Code: C

1. byteVariable = 0;

In fact, such a reduction is exactly what the C++ optimizer will do to such an expression at compile time to optimize it for either speed, or size, or both.

To add a comparative flavor to it, you are supposed to use a C++ equality operator == explicitly like so:

Code: C

1. byteVariable = (byteVariable == 0); // this is the only sensible place to put == at

in which case the resultant byteVariable will again evaluate to 0 (C++ false, or C FALSE) at all times unless it's been reset to 0 beforehand, in which case it will evaluate to 1 (C++ true, or C TRUE) thereafter.

[Brian Alvarez]

 Hello Mike,

 Before assignment, there must be an evaluation of the statement, and since:

After investigating this Assignment-versus-Equality problem, I will allow (a=b) to be an equality expression instead an assignment expression. This will now have the same behaviour as (a==b)

 I am trying to stick to all rules, C++, Oxygen and PluriBASIC. Not easy, but im trying.

 PluriBASIC does all sorts of modifications to the code, it also supports == and can differentiate it from =.

Note: The oxygen examples here expressed for example purposes, are not the final code i am trying to support, but an example of the functionality i would like to have in Oxygen in order to support other statements not expressed in here.

[Mike Lobanovsky]

Hi Brian,

... Before assignment, there must be an evaluation of the statement ...

(boldfacing is mine)

No, not in C++. And you said you were "doing c++ compilations", didn't you? That's why I reacted the way I did; I thought you might be not fully aware of what you were doing in C++. I'm glad my supposition turned out to be false. But I did have the right to check it after all, didn't I?

Regarding

After investigating this Assignment-versus-Equality problem, I will allow (a=b) to be an equality expression instead an assignment expression. This will now have the same behaviour as (a==b)

I don't think it was one of Charles' best design decisions. But then I let it pass without a comment. "Let's live and see where it takes him to", I thought.

Now it has taken us all right here. There is not a single reason for the Oxygen language to have a == operator and not use it in cases like this.

[Brian Alvarez]

 Hehe, yes, you are right Mike. I was just trying to keep my explanation as simple as possible.

 IMO, Charles was kind of right... if you take in account the fact that Oxygen can easily detect by the
context wheter it should be comparison or assignment. But since Oxygen also supports Scopes, thats
another thing. But AFAIK, Oxygen does not take () as a context separator... only blocks... right?

 There are also situations in which  i think C++ developers didnt make the best desitions, so, Charles
is improving on that.

[Mike Lobanovsky]

In fact, Charles is doing a wonderful job of improving on three syntaxes at once, C, BASIC, and asm.

There's a hell of a lot of alternative syntaxes for common expressions in OxygenBasic, so I can't figure why he would deliberately restrict himself to the most clumsy one (classic BASIC's ambiguous evaluation/assignment) instead of just adding a note to his future Help file that to impose the BASIC rules in this particular case, one is supposed to use == instead of the clumsy =.

(If my memory serves me, there is also a === operator in the O2 paradigm... )

[Arnold]

True or not true, this is the question. Some say true is 1, some say true is -1, some say true is everything but 0, some say these are alternative facts.

[Brian Alvarez]

Arnold, while i agree with the fact that anything that is not 0 is true,
if the value of true can be overriden there must be consitency with
the internal behavior.  It doesnt matter if it is -1 or 1 or 42.

Take this silly situation for example:

Code: [Select]

def true -1

function preserveFiles() as long
    int isItImportant  = true
    int isItUniqueCopy = true   
    return (isItImportant = isItUniqueCopy)
end function

' Do i save the really important file?
int keepFiles = preserveFiles()

if keepFiles = true then
    print "I will keep this files."
else
    print "Off with their heads it is!"   
end if

[Mike Lobanovsky]

Brian,

Your code in its if keepFiles = true then part is again unsafe!

For the sake of code flexibility, most languages do not guarantee or require that each of the components of a Boolean expression always evaluate to either true or false. They only guarantee that false will always evaluate to 0 regardless of what value is actually assigned to true by convention or redefinition.

From this perspective, the only other guarantee they can give is that any value that is non-false will evaluate to true if used in a Boolean expression. And it can be demonstrated that such a two-clause contract is perfectly sufficient to assure that the user can design Boolean expressions of any complexity without the need to cast the operands to anything else besides what they already are, provided the user is proficient enough in what they are doing.

To work around the unsafety of your code and similar user frivolities based on what you're requesting in this thread, the language designer should either

• Introduce a strong Boolean (bool, BOOL) data type and hide all the associated casting procedures within the language core engine, to reduce all integral data types to the predefined false and true values when used in Boolean expressions

or

• Introduce an IsTrue()/IsFalse() pair of explicit functions that would do the same for all integral data types explicitly, and notify the user that they must use those functions to make their code fool-proof at all times.

As we know, Bob Zale preferred to follow the second option in his PowerBASIC.

OTOH in what regards your unsafe example, the offending statement should simply be changed to

Code: OxygenBasic

1. if keepFiles <> false then

or

Code: OxygenBasic

1. if keepFiles then

which will make it absolutely safe, and the entire problem may then be dismissed as wrongfully attributed to a deficiency in the language rather than a deficiency in one's coding style.

[Brian Alvarez]

 Mike... that was just an example.

 Besides, for newcommers, it would be fairly easy to assume that just by comparing something to
TRUE it will evaluate as true no matter what the true value is... like an almighty native statement
that evaluates like an istrue.

 I know the code is unsafe. I know why it is unsafe, I know how to make it safe. I just would like
a little bit of consistency. That is all i am asking for. So i can be able to write the exact same code
and compile it to any laguage as i want. Im not dealing with a single target here. Im asking for a
feature that i cannot do myself, in order to be able to multitarget the code. Please consider that when
telling me how can i improve code that is intended as an example.

I am thinking beyond my needs here. I am thinking beyond a caprice. I really would like not having
to explain too much unless necessary.

 I would like to be able to do this:

Code: [Select]

Config.switchframe = (Config.switchframe = 0)
 And know it will compile exactly the same for all platforms without having to do this:

Code: [Select]

        if Config.switchframe then
            Config.switchframe = 0
        else
            Config.switchframe = 1
        end if
 Consistency. Thats all i would like. If i had some control over this i wouldnt be asking. Why do you
seem to be against it? What gives? Im just trying to save the future-me and others PB'ers used to true
being -1, from wasting time looking for a bug regarding true being 1 instead of -1 when copy-pasting
existing code in the IDE.

I know your advise is good... but i (or you) wont be there to explain that to everyone using oxygen, that
even though you just told oxygen what true means... it will still use a different true and let you use your own,
just like two unconsiderate strangers.

 See the compiled examples attached. Its not finished, but both use:

Code: [Select]

Config.switchframe = (Config.switchframe = 0)
 I know what i have to do. I know what i cant do from here. I ask what i cannot do myself. I try to explain
the best i can. I ask for a switch that wont affect others. Can i have my switch and be on my way?

 Because... if i cannot have consistency between platforms, for one simple issue i dont have any control
over, why should i go on?

... Also.. istrue and isfalse in PowerBASIC are operators, not functions.


 

[Mike Lobanovsky]

Brian,

First and foremost, let's make it straight: I understand your concern and I appreciate the work you are doing. Sometimes (like this time seeing your game intros above) I even admire it.

But then, i) the PB'ers who are still there to re-baptize into O2 are long since accustomed to successfully treating Boolean expressions the C-style (that's what I'm advocating here) trashing that IsTrue/IsFalse childish nonsense altogether, thanks to it being feasible in PB; and ii) I fear lest you drag Charles into another, yet deeper dive into the restrictive BASIC syntax instead of rolling back to clear and concise a==b since the == operator is already there in the language vocab. Note Power-/PluriBASIC's are not the only languages that can now be implemented based on the O2 core engine, and tailoring its paradigm to your immediate needs day in and day out would be unfair to those other languages.

I still consider dropping the compound assignment feature in favor of questionable benefits of BASIC-like a=b eval a major regression of the language.

I really would like not having to explain too much unless necessary.

I'm afraid this is exactly one of the cases when you will have to explain yourself in one way or another because there are at least three opponents here who would like to hear you out, and those are me, myself, and I.

Config.switchframe = (Config.switchframe = 0)

Does your JavaScript that you're evidently using for your Android compatibility allow you to do just that? I doubt it. Then what should I do with your a=b and no compound assignments if I ever prefer to implement, say, a C interpreter based on the O2 engine? Re-write/fork O2 to revert its BASIC-ish flavor and bend it again to my C needs that already were there originally? Why should it be me and not you?

So, I am not just flooding the topic. Instead, I am indirectly giving more chances to Charles to re-think once again if O2 should be tailored to one specific customer where everything you need may be implemented at a functional or macro level in your PluriBASIC translator rather then in the O2 core engine.

Because... if i cannot have consistency between platforms, for one simple issue i dont have any control over, why should i go on?

Hehe, just don't bulldoze us here; having O2 and its compatibles at our disposal, we have no real need or use for PowerBASIC.

Anyway, the answer to your question is simple and obvious: because you can!

... Also.. istrue and isfalse in PowerBASIC are operators, not functions.

Oh! Thanks for reminding me; haven't had to code anything in PowerBASIC for years.

[Brian Alvarez]

 Hello Mike, please read this post with a friendly voice, like i was there and we were having a normal disussion, maybe drinking a beer. I dont want you to think i am being agressive or anything. I just like to be direct.

the PB'ers who are still there to re-baptize into O2 are long since accustomed to successfully treating Boolean expressions the C-style (that's what I'm advocating here) trashing that IsTrue/IsFalse childish nonsense altogether, thanks to it being feasible in PB

You are generalizing, you, yourself and Mike do not count as "the PB'ers".

...I fear lest you drag Charles into another, yet deeper dive into the restrictive BASIC syntax instead of rolling back to clear and concise a==b since the == operator is already there in the language vocab. Note Power-/PluriBASIC's are not the only languages that can now be implemented based on the O2 core engine, and tailoring its paradigm to your immediate needs day in and day out would be unfair to those other languages.

First of, Oxygen IS a BASIC. Besides this code:

Code: [Select]

a = (a == 1)
Is still supported... you know? Also, since when did == form a part of the BASIC language vocab?

Second, the desitions Charles took are his desitions and I had nothing to do with it. If he decided/decides to implement ==, i am perfectly fine with it. You don't know what you are talking about when you say i am "dragging" charles. I am merely using a feature of this forum that is precisely intended to request features... not to order them. Charles decides if implementing them or not. Second... me... dragging him into creating a restrictive Basic? Mike... do you realize that what i am asking is for more freedom? Do you realize that he already implemented a way to change the value of true and that i am merely asking to get it consistent with the internal evaluations? Do you realize i am not asking him to change 1 to -1 for eveybody, but simply asking for a switch, that would need to be explicitly used, and would not affect others or limit them?... It would give others the ability to use what they may or not be used to receiving out of a statement evaluation.

I still consider dropping the compound assignment feature in favor of questionable benefits of BASIC-like a=b eval a major regression of the language.

Fine. Make your own request for Charles to brings it back and let him decide, instead of blaming me because he hasn't.  Who knows, he may fully implement it (since it currently works fine, fully implementing it means it would drop support for = in evaluations... read: drop a BASIC functionality, drift away from BASIC... etc), and if he does, its fine with me. I wont make posts in your request telling him why it would be a bad idea. Because that would be trying to drag him into asking for a restrictive basic. In fact, it seems like YOU are trying to drag him into creating a restrictive BASIC flavor by saying -1 is not necessary and 1 will do...

 When you say "questionable benefits", you make it sound like I asked charles to drop the compound assignment feature. I did not, you know? Also you dont know what you are talking about when you say "regression of the language". As i said before, AFAIK BASIC never went in the direction of ==, I might be wrong, but most BASIC flavors use =, the == is a C++ thing (a different language, not BASIC, like in OxygenBASIC). A language cannot go back from a place it never went to, if charles or me implemented == It doesnt make it canon to BASIC, but an extra he and i wanted to implement to support other languajes, just like -1 would be supporting other languages... no wait.. not other languages, but BASIC, like in OxygenBASIC. So it looks to me like it is you who is trying to drag him out of the BASIC and into C++, while im trying to get a BASIC feature, the language he choose for the compiler he is working on. Im not even trying to drop the C++ style: 1.

I'm afraid this is exactly one of the cases when you will have to explain yourself in one way or another because there are at least three opponents here who would like to hear you out, and those are me, myself, and I.

 If you ever create something like Oxygen, and I decide to implement it in my project, then i might consider explaining more to you. In the meantime you all 3 guys are going to have to live with it. Sorry. 

Of course if Charles asks me to advocate for my request, I will.

Does your JavaScript that you're evidently using for your Android compatibility allow you to do just that?

Yes. But its not so evident if you dont notice is Java and not JavaScript.

...I doubt it. Then what...

Woa... I already said yes, no need to continue a statement based upon a false assumption. Of course that, since this project uses Windows API calls, it would not compile for Android unless all of the APIs were converted to Android.

So, I am not just flooding the topic. Instead, I am indirectly giving more chances to Charles to re-think once again if O2 should be tailored to one specific customer where everything you need may be implemented at a functional or macro level in your PluriBASIC translator rather then in the O2 core engine.

Mike... what are you talking about? I am not asking a feature for only me.... i have repeatedly written that i would like to be able to get the output others may be used to. And no, this cannot be implemented at a macro level. You may think it is evident, but trust me, it is not. It would require me to break the statements into several parts and in other posts i have said that feature is not yet implemented.

Hehe, just don't bulldoze us here; having O2 and its compatibles at our disposal, we have no real need or use for PowerBASIC.

 Yes, i get it you like other language. This sentence is dripping an obvious dislike for PowerBASIC... but even if not, I will not go against it. You are free to like or dislike whatever. Oxygen is a BASIC, you know? It looks to me like you really want Charles to turn it into a C++ or something. I don't mind, request away!

Oh! Thanks for reminding me; haven't had to code anything in PowerBASIC for years.

 Yes, this one too. And the first sentence too... Are you trying to "hurt my feelings" or something? Because i dont mind if you dont like PowerBASIC. Its not mine, you know?