What's your philosophy about constants?

[CharlieJV]

So putting on your QB64 hat and/or a "BASIC in General" hat ...

I wasn't happy with wwwBASIC's implementation of constants, very early stages, direction I wasn't crazy for (search for third occurrence of"'const" on that page if you dare), so I decided to rejig things in BASIC Anywhere Machine's fork of wwwBASIC.

Without planning on it, I wound up with the CONST statement working exactly like a "FN-less" and parameter-less version of DEF FN.

So now the following code runs A-1 in my dev version (EDIT: now in my online version) of BASIC Anywhere Machine:

Code: QB64: [Select]

1. dim currMiles#
2. const currKilometers# = currMiles# * 1.60934
3. '-------------------------------------------
4. do
5.         cls
6.         input "enter number of miles: "; currMiles#
7.         print str$(currMiles#) + " miles, that's: " + str$( currKilometers# ) + " kilometers."
8.         print : print "press a key to start again" : while inkey$ = "" : wend
9. loop
10.  

Although totally unorthodox for BASIC, there's something I semantically really like about it.  A special soupçon of je-ne-sais-quoi.

It has me wondering, though, what dp die-hard BASIC folk think of that?  Does it just annoy you?  Or give you the creeps?  Or is this a total 5-alarm fire ?

And how would you do this in an orthodox QB64 (or general/traditional BASIC) way ?

[Pete]

Code: QB64: [Select]

1. DIM currMiles#
2. CONST ConvertMilesToKilometers# = 1.60934
3. '-------------------------------------------
4. DO
5.     CLS
6.     INPUT "enter number of miles: "; currMiles#
7.     PRINT STR$(currMiles#) + " miles, that's: " + STR$(currMiles# * ConvertMilesToKilometers#) + " kilometers."
8.     PRINT: PRINT "press a key to start again": WHILE INKEY$ = "": WEND
9. LOOP

I miss DEF FN, too, but by definition, CONSTANT means a variable that never changes. That is to say the compiler sets aside less space, because it is a fixed value.

I had a discussion in antoehr thread about this, let's see...

"I hardly ever use constants. From the old days, it was a way to save that coveted stack space. This is because a constant is compiled with less allocated space, since the compiler knows it won't be changing in value. Those days are behind us, so this type of optimization is now more of a coding preference than a necessity for large applications. Readability is somewhat an advantage to constants. The programmer, or someone else studying the code, is informed of the variables which are fixed. No need to track them when debugging. For coders who have a hard time keeping things straight, constants prevent the mistake of taking a non declared variable, meant to be a constant, and mistakenly assigning it a new value, someplace in the code. That's called OOPs programming!"

Pete

[CharlieJV]

(SNIP!)

I guess I'm seeing currKilometers# as being (tongue in cheek) CONS(IS)TANT(LY), or CONSTANTLY matching currMiles# ...

Groan ...

[STxAxTIC]

my ted talk on const, 2022 edition:
const is completely redundant to ordinary variables, and its implemented more stupidly. so don't use it.
no, i mean it: const is nothing but a brain diaper. if you aren't sure whether you're editing your variables, you should go use an easy language like QBAS--- wait. step away from the computer instead.
... and that's what i say!

my credentials for having this opinion:
i do motivational talks for battered women and entertainment at youth mitzvah parties

[bplus]

I use constants they are very handy, change one value in code and throughout your program the values are updated.

Only a fool would argue against such a convenience.

[CharlieJV]

(SNIP!)
const is completely redundant to ordinary variables, and its implemented more stupidly. so don't use it.
no, i mean it: const is nothing but a brain diaper.
(SNIP!)

I've got a couple of cognitive disorders going on, so I rely heavily on well-organized (EDIT: "well" is definitely in the eyes of the beholder, so let's say "organized to the gills in a way that fits the particular brain"), with very visible yet non-distracting visual cues to understand and remember.

Just saying I need that brain diaper because of cognitive incontinence.

How fortunate are those without dependence on a brain diaper?  (Yeah, a little envious am I ...)

Self-deprecating humour aside, them are great points.

[Pete]

@bplus That's the most common use for "constants" in a program, but you don't actually need the CONST to do it...

pi = 3.14159
' blah, blah, blah
PRINT 27 * pi
' blah, blah, blah
PRINT pi / 2
' etc, etc., etc.

So just change the variable pi at the top, to any number of acceptable digits, and it works just the same as CONST, except it won't throw a compiler error if you mistakenly assign pi to a different number someplace else in the program.

Pete

[bplus]

Which is easier to type:

Const pi = 3.1415

or

Dim Shared pi as some type
pi = 3.1415

[CharlieJV]

I use constants they are very handy, change one value in code and throughout your program the values are updated.

Only a fool would argue against such a convenience.

Ditto.  (Except fool.  Anybody's fool might just be my Huckleberry for one thing or another...)

Although that can just as easily be done with a variable, constant has a certain cognitive soupçon of je-ne-sais-quoi along with a "define me and I will protect thee from thyself and any muck-ery which might be afoot down the road" safeguard.

[bplus]

"define me and I will protect thee from thyself and any muck-ery which might be afoot down the road"

LOL yes!

[CharlieJV]

@bplus That's the most common use for "constants" in a program, but you don't actually need the CONST to do it...

pi = 3.14159
' blah, blah, blah
PRINT 27 * pi
' blah, blah, blah
PRINT pi / 2
' etc, etc., etc.

So just change the variable pi at the top, to any number of acceptable digits, and it works just the same as CONST, except it won't throw a compiler error if you mistakenly assign pi to a different number someplace else in the program.

Pete

In a huge program with a lot of stuff going on and risk of typos, I could imagine defining something as a constant could help to easily catch a mistake when at some point assigning a new value to something that was meant to stay a constant.

Danged if I can think of a good example off the top of my head...

[SMcNeill]

In a huge program with a lot of stuff going on and risk of typos, I could imagine defining something as a constant could help to easily catch a mistake when at some point assigning a new value to something that was meant to stay a constant.

Danged if I can think of a good example off the top of my head...

A good example would be:

CONST True = -1

Now, instead of typing IF x = -1 THEN....  you can type IF x = True THEN.... 

This helps catch basic typos such as typing IF x = 1 THEN... (you forgot the minus there, or the keypress didn't register from too much Cheetos-dusting...)  Especially in conjunction with OPTION _EXPLICIT, you'd get a notification when you typed IF x = Tru THEN...

Names are more readable and have the added security of enhanced syntax checking.

[OldMoses]

I've used them on occasion, mostly for conversion factor stuff, but generally don't see the point. Use a shared variable that you don't change and it's the same thing as far as I can tell.

[tomxp411]

The whole point of a constant is that it can't be modified. The other point is that it's a literal replacement made at compile time.

Let's look at one of list of constants built in to the DotNet SDK, the keyboard scan codes. There are 773 keyboard scan codes in the System.Windows.Forms.Keys enumeration - just for a list of keys on the computer.

Now consider all of the other thousands of enumerations and constants in the system... the "Magic Number Database" has over 380,000. That's not all of them, either. So if you were to include all of the constants your program might need as variables every time you compile it, you would be adding in over 1.5 megabytes just for the variable storage, not to mention the other things that go into storing and retrieving a variable.

So there are two very important reasons to use CONST in your program:
1. It's an obvious semantic flag that says "this value isn't going to change."
2. Those values get converted directly to data during compile time. There's no variable storage or lookup for those values, and unused constants actually disappear from the object code, saving even more space.

Does it matter in a little dinky 30K demo? No. But does it matter in large applications, spanning thousands of source files and multiple megabytes of object code?

Absolutely.

[CharlieJV]

Just wanted to say thanks for all comments.  I've decided to introduce a new statement called "EQN" (for equation).  Although EQN and CONST use the same background stuff to implement them, I like the semantic differentiation.  I'm not liking a CONST statement allowing appearance of not looking like a constant.

If anybody knows of any BASIC that already has an EQN statement or function, please let me know.

Imagine an income tax program or something like that, here's how EQN works:

Code: QB64: [Select]

1. dim line1, line2, line4
2. eqn line3 = line1 + line2 , line5 = line3 + line4
3. line1 = 3 : line2 = 7 : line4 = 4
4. print line1
5. print line2
6. print line3
7. print line4
8. print line5