Proposed change to QB64 regarding CONST

[SMcNeill]

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.

[STxAxTIC]

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.

[codeguy]

How about having an IDE option to set stricter checks using metacommands, perhaps '$QBStrict+, and default to $QBStrict-.

[bplus]

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?

[STxAxTIC]

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.

[SMcNeill]

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...

[SMcNeill]

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.

[SMcNeill]

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.

[FellippeHeitor]

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.

[Qwerkey]

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.

[SMcNeill]

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...

[Qwerkey]

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!

[STxAxTIC]

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.

[codeguy]

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.

[_vince]

Great idea, Steve!