Simple feature request regarding TRUE.

[Charles Pegge]

Compound assignment is rarely used, but it is still available with slightly stronger-smelling syntax borrowed from Pascal. Then there is no ambiguity:

Code: [Select]

int a,b,c,d =5
a := b := c := d
print a " " b " " c " " d

I think true as -1 (32 bits set) is the safer option for Basic, since it does not clearly distinguish bitwise-logic from boolean-logic.

For instance, bitwise not breaks the intended logic when comparators return 1

Code: [Select]

int a,b,c
c=not((a<=b)or(a>=b))
print c


o2 comparators currently return 1 or 0, and are not affected by the definition of true. But for an extra 2 byte instruction and a clock cycle, this is easily changed.

[Brian Alvarez]

o2 comparators currently return 1 or 0, and are not affected by the definition of true. But for an extra 2 byte instruction and a clock cycle, this is easily changed.

 Thanks charles! That will make it more consistent with the macro definition.

[Mike Lobanovsky]

WoW Brian,

Wasn't that some tl;dr!

Okay do with O2 whatever you want. It won't hurt us (me, myself, and I) much because if we ever want or need to, and provided the Oxygen license stays as permissive as it is now, we will always be able to fork it back to what it used to, or should, be from our perspective.

In fact, my one and only concern about O2 is that it stays as compatible with C, in general, and C headers, in particular, as it has always been. This is the very reason why I'm so sensitive about every mod or feature that makes O2 drift away from the mainstream it has always followed, even if that drift is towards classic BASIC. Which, incidentally, makes your

A language cannot go back from a place it never went to ...

a false assumption.

... this cannot be implemented at a macro level. You may think it is evident, but trust me, it is not.

No sir, I will not trust everything I hear because my own experience would not permit me to. I used to be a co-worker on the BCX translator project now almost 20 years ago, and an author of its fork called NuClear BASIC (NCB) a little later. In fact, almost the entire DYNACALL engine the both incarnations hosted was originally my initiative. So, every challenge you're currently facing with your PluriBASIC translator used to be mine too until it was resolved one way or another.

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

Wrong. We count as the users of almost every worthwhile BASIC out there in recent two decades or more. And I am still an official member of the PB Peer Support forums pretty much as you are.

If you ever create something like Oxygen ...

Done triply in FBSL and some places even faster than Oxygen though granted, in 32 bits only. So, in fact your conditional should've rather been an assertion.

... and I decide to implement it in my project ...

With my kind permission, I presume?

Though no, should I ever decide to implement anything like an alternative PB, then there would be no compromises. It would be a full stack implementation from a dedicated lexer to a machine code compiler (or two, or even three).

... then i might consider explaining more to you.

You don't really need to. In view of what I already said above, I'm reading between your lines almost as easily as if I were reading your PluriBASIC sources.

OK Brian, I think we've gone a long way to know each other better. Have a nice day and thanks for the beer.

[Brian Alvarez]

 Hehehe, you are welcome Mike.

 Dont worry, I doubt Charles would like too much to loose compatibility with C++ (neither would I), so, you are pretty safe IMO.

 You gave me an idea to make ISTRUE and ISFALSE a function instead of an operator. I already changed it. It is more clear now.

 Why dont you make a compiler? Maybe i could hassle you too.

 

[Aurel]

i don't like to talk to much but i know one thing:
I don't like the idea of having predefined TRUE/FALSE as keywords
leave it to the user .