Why are constants global?

[dell_jockey]

I just stumbled accross something I didn't know untill now: constants apparently have a global or at least a file-global scope. I can't declare constants with the same name in multiple procedures that reside in the same source file.

Why is that?

The help file says that constants are merely replaced by their value at compile time.
Why can't the compiler limit the scope of a constant to a procedure, when this constant was defined within that procedure?

If the above is a correct interpretation, please consider this a feature request.

Thanks!

[Trond]

Constants would be very much less if they weren't accessible everywhere. Let's just imagine that all the standard constants, which are declared in a resident file, were not available anywhere outside that resident file.

[dell_jockey]

Constants would be very much less if they weren't accessible everywhere. Let's just imagine that all the standard constants, which are declared in a resident file, were not available anywhere outside that resident file.

I'm not pleading for procedure-scope only constants. I'd like constants to be visible in the context of where they were defined.
- If defined in a file - outside a procedure - a constant should be visible everywhere within that file.
- If defined within a procedure, it should be visible only there. If within a procedure a constant name is reused that already has scope above the procedure level, is should be interpreted as a re-defintion, but only so within the scope of that procedure.
- constants in a resident file should of course remain global and non-redefinable within a procedure...

Just a thought....

[Irene]

Why not just use a Static variable inside a Procedure?

[dell_jockey]

Why not just use a Static variable inside a Procedure?

I'd rather not, because constants are immutable. This property would ensure that they will not be changed. It's an extra layer of security if you will...

Whatever, since that is not available right now, I'm indeed changing my constants to 'static doubles'. A kludgy alternative in my opinion, but so be it...

[srod]

But constants that can be redefined, even within the context of local scope etc, are not constant!

Constants are imutable and thus it makes sense to have them globally scoped, at least in my opinion!

[Irene]

at least in my opinion! :)

And that's what counts most doesn't it? ^_^

[srod]

[Irene]

:?:

Just a little joke my friend @_@

[srod]

Ah, not familiar with the @_@ kind of symbolism I'm afraid.

All those years spent living in a tree I guess!

[Rescator]

Anime/Manga emoticons, you'll get used to them. Look on the bright side, won't have to tilt your head to figure them out ;P

[pdwyer]

My 2 yen,

I would always assume constants to be global in any compiler I use. There are so many of them that usually they will be defined in other included source files. Think of all the constants for the win32api, these are not special or any different to ones you create yourself. It's not like these API ones are "Built in" constants which are global and "user defined" constants which are otherwise. There are just constants.

IMO, if constants have scope then what's constant about them?

If you write a module and create an include file, it would be a mess if you had to get people to define all your constants again in their procs.

Maybe I'm not understanding

[Dr. Dri]

I think Fred talked about a module/endmodule keyword (for a future version) wich looked like a kind of namespace

Dri

[electrochrisso]

I believe that all constants should be global just like they are for the overall operating system ones and that way only one namespace is assigned for it.

[Kaeru Gaman]

me too.
a Constant is for defining something like #PI

there is no reason, why a constant should change it's value.

a constant is meant to be constant, like pi or e or Planck's constant...
they will stay the same whereever in the universe you may move to.

so, a namespace scope will completely negate the basic idea of a constant.