QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: SMcNeill on October 20, 2018, 10:16:22 pm
-
Here's a change which I was thinking of making for QB64, which doesn't quite follow the old "rules" of the syntax checker, and I wanted to get people's thoughts on the change first.
What I'm thinking of doing is altering CONST to ignore duplicate labels if the values are the same, rather than tossing an automatic error message.
FOR EXAMPLE:
CONST example = 1
CONST example = 1 <--- this second line would toss an error for duplicate definition, and I want to just ignore it instead.
Now, if CONST X = 1: CONST X = 2 were to occur, this would ALWAYS be grounds for an error as the values don't match; but, if they do, then why not just ignore the duplicate??
The reason for this proposed change??
Common CONST across libraries such as CONST TRUE = -1, FALSE = 0.
These terms -- and values -- match across multiple libraries, but they still toss errors. I'd like to dig into QB64 and change that, if I can, and if nobody rejects the idea.
-
Thumbs down in my opinion. This is like unplugging the check engine light on the dash. If an error is thrown, fix the actual error, no?
The real-world scenario goes like this: suppose someone (besides you) is debugging QB64 in the future, and stumbles across contradicting, or at least duplicated - CONST values for the same label with *no* error or warning thrown. That coder will have to puzzle for himself just which value is being used. "Just look at the execution order" you might say. Fine. But would you continue in this spirit or regret this method if say, multi-threading becomes realized? Not to digress in that direction...
I would recommend layering things properly so that contradicting or redundant CONST values are engineered out by good habit, not simply made invisible by a patch.
-
How about having an IDE option to set stricter checks using metacommands, perhaps '$QBStrict+, and default to $QBStrict-.
-
Why not just throw the error if the const values are different? If they are the same, ignore...
Oh you said that, so yeah, I agree ;)
I mean where's the error at if the are the same value?
Under the hood would they have different addresses?
-
In the end I guess I don't care how it goes - not like I'll be trudging through all that any time soon.
I'm gonna know exactly who to blame though, when they say "I commented out this CONST statement but its still doing something"... little did they know there's another one just willing to step into the compiler.
Bad bad bad. Buuuuuuuuut yeah - not my problem really.
-
In the end I guess I don't care how it goes - not like I'll be trudging through all that any time soon.
I'm gonna know exactly who to blame though, when they say "I commented out this CONST statement but its still doing something"... little did they know there's another one just willing to step into the compiler.
Bad bad bad. Buuuuuuuuut yeah - not my problem really.
Which is more annoying -- commenting out one CONST and having a second replace that value, or having to open half a dozen library files and have to comment out duplicates when they occur?
Most CONST which would be commented out, aren't the standard ones you'd see repeated multiple times across libraries.
CONST SaveToDisk = TRUE <---- this sounds like a CONST that might be remarked out, but it doesn't seem to me that it's something which would be common across multiple libraries, or included in code multiple times.
CONST TRUE = -1 <----- this, however, we see in a lot of libraries. As a library writer, TRUE is nice for readability, but we're left with a few choices for the library -- all bad:
1) Include it in our code, and then have users experiencing issues with duplicates.
2) Exclude it from the code and rely on the user to manually add these values, and then field and try to debug error reports when they don't.
I suppose a few other ways to handle the issue would be to add a new precompiler command, or a new expanded CONST command:
$IFDEF TRUE THEN
'Do nothing
$ELSE
CONST TRUE = -1
$END IF
OR perhaps:
RECONST TRUE = -1 'Much like REDIM vs DIM, we offer a REpeatable CONST
*************
Of course, this then ends up with all the old libraries having to be rewritten and then the new versions not working on older copies of QB64 anymore...
-
Thumbs down in my opinion. This is like unplugging the check engine light on the dash. If an error is thrown, fix the actual error, no?
The real-world scenario goes like this: suppose someone (besides you) is debugging QB64 in the future, and stumbles across contradicting, or at least duplicated - CONST values for the same label with *no* error or warning thrown. That coder will have to puzzle for himself just which value is being used. "Just look at the execution order" you might say. Fine. But would you continue in this spirit or regret this method if say, multi-threading becomes realized? Not to digress in that direction...
I would recommend layering things properly so that contradicting or redundant CONST values are engineered out by good habit, not simply made invisible by a patch.
As I said before: Now, if CONST X = 1: CONST X = 2 were to occur, this would ALWAYS be grounds for an error as the values don't match; but, if they do, then why not just ignore the duplicate?
I'm only suggesting allowing errors to be ignored if values match.
CONST TRUE = -1
CONST TRUE = -1 <---- Why toss an error here? It's just reaffirming the original value.
-
Why not just throw the error if the const values are different? If they are the same, ignore...
Oh you said that, so yeah, I agree ;)
I mean where's the error at if the are the same value?
Under the hood would they have different addresses?
There are no addresses, "under the hood". Just a basic substitution list that changes one value for another with the translator.
We type:
IF X = TRUE THEN
The translation is:
if (X==-1) {
Our substitution list just changes TRUE to its set value. (Usually -1.) That's basically all CONST does for us.
-
I personally don't love it either.
You CONST TRUE = -1 and get a duplicate definition because you are using a library that already set it to -1, then you remove that CONST line you'd just written.
If you happen to conjugate two libraries and they eventually did set TRUE to some value, I imagine two scenarios:
1- Libraries working together require preplanning anyway. They're either by the same author OR
2- They are by different authors that didn't preplan interaction and a user's intent to join their functionality supposes some extra work anyway.
Here's a personal example: I've recently adapted Zom-B's GIF player found in the WIKI so it could be integrated into InForm's next release. There was no TRUE/FALSE consts in there but there was a bunch of adaptations I've had to do to get it to interact properly with my code. That type of extra sweat was not intended by Zom-B when he wrote it, but neither was the integration.
-
Hmm. Steve sets us a conundrum.
If more than 1 CONST statements give the same, why bother to check? Does seem reasonable.
But maybe we feel (I do) that a CONST statement should only appear once anywhere in the code.
However it ends up, I'm sure that the Wiki will be appropriately updated.
-
I personally don't love it either.
You CONST TRUE = -1 and get a duplicate definition because you are using a library that already set it to -1, then you remove that CONST line you'd just written.
If you happen to conjugate two libraries and they eventually did set TRUE to some value, I imagine two scenarios:
1- Libraries working together require preplanning anyway. They're either by the same author OR
2- They are by different authors that didn't preplan interaction and a user's intent to join their functionality supposes some extra work anyway.
Here's a personal example: I've recently adapted Zom-B's GIF player found in the WIKI so it could be integrated into InForm's next release. There was no TRUE/FALSE consts in there but there was a bunch of adaptations I've had to do to get it to interact properly with my code. That type of extra sweat was not intended by Zom-B when he wrote it, but neither was the integration.
It's not so much an issue of pre-planning, as it is an issue of independent redundancy.
Here's a personal example: Recently, I was playing around with a program that made use of Terry's Menu library, my Text library, and my Frame library. All three of these set TRUE and FALSE as CONST, which left me scratching my head pondering how to proceed. These are all independent libraries, ALL use True/False settings, and they're not all going to be needed for every project. So, do I:
1) Remark the line out of the libraries, maybe making them unrunable for other programs that use them? (Or only use one of them?)
OR
2) Make a copy of the files, rename them slightly ("MenuLibrary -- NoTrue.BM"), and have an extra copy cluttering up the drives, and then use those versions after I remark the CONST out?
Or, option 3: Since the values are the same, just teach QB64 to ignore those duplicate labels.
**************************
I guess one way around the issue would be to use the precompiler we have.
$IF TRUESET = FALSE THEN
CONST TRUE = -1, FALSE = 0
$LET TRUESET = TRUE
$END IF
The first time QB64 encountered this, it'd set the CONST values (and precompiler TRUESET value), and the rest of the time it'd overlook them completely...
This would require a change to a whole lot of libraries though, and folks would have to agree to abide by the same standard or else it won't help any. (For example, say my libraries use TRUESET as the flag, while Terry's uses TRUEFALSE as his flag, and Rho's uses COMMONLABELS for his...
-
Yes, that is a conundrum. I was only thinking of "My Own Work" + "One Library". With multiple Libraries, what do you do? Executive decision required!
-
So once we settle this one, do we do it all over again for anything defined as DIM SHARED?
I cant hand-wave enough to handle this issue correctly instead of double down on a badly-received idea.
-
Enforcing the CONST rules as in QBxx would prevent headaches in the future. Yes, WE know, but then you have people womdering why qb64 code that has only QBxx keywords isn't working in QBxx. This also helps teach proper structured programming. I don't think any other language lets this pass without error. It's not being strict as that's a rule imposed by the designers of QBxx, probably the same as the language it was coded in.
-
Great idea, Steve!
-
Steve, do you make 1 BI for the 3 combined libraries or attempt to use the 3 BI's (separate and independent) already ready?
I think you attempt the latter choice and I think the former choice would solve the issue.
It's clear to me, both Fellippe and STxAxTIC are intuitively against the idea though The Disaster Example has not yet been presented.
So the conservative move is probably to wait ie for The Disaster Example to raise it's ugly head.
Constants don't use Type so that can't be a problem either unlike SHARED.
-
If this is mainly about al that CONST TRUE.... thing, then i'm glad to use literal numbers in my libraries. Typing 0 or -1 is shorter than typing TRUE or FALSE.
However, the approch seems ok to me, if the CONST's name AND value are equal, then just ignore the double definition. But maybe it should be restricted to equal literal values only, not if the CONST's value is based on an expression or function result?
-
Hi
question: Do we teach to parser to ignore duplication of statement about CONST if they are made the same definition (for name and value)?
summarizing the different opinions showed until now:
let's make Pro and Cons
Pro
- no headache for error that are no error (a CONST doesn't change)
- high feasibility to combine library of different authors and/or ispirations
Cons
- no documentated feature of BASIC language
- if we change one definition of CONST we fall in the issue of duplicate of name because the others are not already changed so we must search the others to change
other options...
-- make a strong changement of QB64 using
$IF TRUESET = FALSE THEN
CONST TRUE = -1, FALSE = 0
$LET TRUESET = TRUE
$END IF
and making a not backward compatibility with previous code.
This can be a feature of compiler activable by settings in menu (this can solve the backward compatibility issue)
-- create a .BI with only UNIVERSAL CONST from TRUE, FALSE... to OPENED, CLOSED, LOCKED, IS_DIGIT, IS_STRING as a global constant file as heat of each program coded in QB64. Just like Steve's .BI for COLOR costants.
-- we can teach to parser/compiler to jump to translate (or to REM) the duplicates of CONSTs, so if coder likes he doesn't care of duplication of the CONST otherwise he go down to delete duplications
Just a my real dubt
Does C++ compiler accept duplicate of CONST?
Thanks to read
-
I'm going to suggest a "meet me halfway" sort of response, splitting the difference between those who say "Yes, ignore a redefined CONST if the value is the same", and "No, throw an error on a redefined CONST no matter what": If the value is the same, throw a WARNING, but let code generation proceed normally. If possible, when throwing the warning, identify the file and line number where it was first defined.
-
Sorry we didn’t proceed with discussion here. We did come to that solution in the chatroom in the end.
-
Chatroom is #qb64 on irc.freenode.net
Come one, come all, stay the rest of your days!