Author Topic: Variable's name unambiguity  (Read 121 times)

acbaile

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Variable's name unambiguity
« on: November 12, 2018, 07:30:55 PM »
    In C i often have following problem. Variables with the same name inside nested blocks. Global/local or local/local. In rules of C new declared variable becomes visible. Variable in higher scope becomes invisible. For example, i give to variables the same name result, and when i continue programming and i think that i operate with one of them - in fact operate with another. Compiling finishes without warnings, but code works with problems. A lot of searching - and f*ck, i have to give another name to this variable here! It happens often.

    For example:

bool
function(){
    bool result = false;

    do {

        /* A lot of code */

        uint32 result = another_function();

        /* A lot of code here, so, i forgot about this declaration */

        // Here - i am sure (!) that i assign value to higher-scope variable :o
        result = true;
   } while(null);

    // Of course, it stays false
    return result;
}

    This example is simple, but happens more difficult cases when searching of reason is much more complicated. I think, this trait of C is bad too. It brings problems to programming. Must be at least warning about ambiguity: "Warning: possible ambiguity".

    Can be some better mechanism to prevent this type of problems?

    C2's modules give very cool improvement of incapsulation of names inside module. Feature as local disrupts it. It is similar to C's header files - it disrupts incapsulation of names too.

    For me personally, it would be better to use all names only with module prefixes, and to receive warnings about possible ambiguity. Even more, i would prefer introducing into the language stricter rules of naming: 1) You can not give the same name to variable in nested block; 2) You can not give to local variable the same name with global of this module. It will give unambiguity. With using of module prefixes it will be harmonic.

    So:

        1) local variables can not have names identical to global variable in this module;
        2) local variables inside one function can not have the same name;
        3) each function has it's own set of local variable's names.

    P.S. Maybe, you are right about overloading of functions. Maybe, it's better to don't have it too. In light of unambiguity.
« Last Edit: November 22, 2018, 09:22:23 PM by acbaile »

lerno

  • Full Member
  • ***
  • Posts: 218
    • View Profile
Re: Variable's name unambiguity
« Reply #1 on: November 12, 2018, 10:23:23 PM »
Sigils and namespacing are two options. Personally I almost never run into the problem you write about. Shadowing variable names is something I have a warning on. I don't remember if C2 made it a warning or error.

bas

  • Full Member
  • ***
  • Posts: 209
    • View Profile
Re: Variable's name unambiguity
« Reply #2 on: November 13, 2018, 08:55:16 AM »
yes definitely an error. Shadowing is a source of bugs

acbaile

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: Variable's name unambiguity
« Reply #3 on: November 13, 2018, 05:47:33 PM »
yes definitely an error. Shadowing is a source of bugs

Let's change?  :)  Rules of naming can be stricter like proposed. If you don't use feature "as local", conflicts of names will be rare, name fields will be wide, convinient. Price - you have to use module prefix all time: string.wcslen(str);
« Last Edit: November 15, 2018, 06:08:32 PM by acbaile »

acbaile

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: Variable's name unambiguity
« Reply #4 on: November 15, 2018, 06:54:05 PM »
If to talk about simplicity of parser, my opinion is: "Ergonomical syntax is more important". Parser is written once during realization the compiler. Ergonomical syntax is used by thousands of programmers during many years.

acbaile

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: Variable's name unambiguity
« Reply #5 on: November 18, 2018, 02:09:16 AM »
    Like for me, it is better to exclude feature as local from the language: for avoiding interferention of names. If you want to call module functions by simple manner, you can use, for example, form as . (dot). Many imported modules can be grouped in root . (dot). Without influence on nameset of module.

    It seems, dot is shortest what can be offered:

        import string as .

        uintreg length = .strlen(str);
« Last Edit: November 22, 2018, 09:23:53 PM by acbaile »

acbaile

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: Variable's name unambiguity
« Reply #6 on: November 22, 2018, 09:21:22 PM »
    I mean, if to introduce strict rules of naming, feature as local will be like "fifth leg for the dog" (russian proverb). It will give additional name conflicts: you can not use names equal to globals of other modules. This merging of namesets that as local does, will give additional conflicts for user's module. It's better to replace it like proposed:

        import string as .

        uintreg length = .strlen(str);

    It seems, form "dot" is short and convinient. And it is very close to regular form "modname.", so it's intuitively understandable what it means.

    Conflicts of names were one of problems of C's header files. Feature as local brings this bad trait of ะก back to C2, again.
« Last Edit: November 22, 2018, 09:25:03 PM by acbaile »

acbaile

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: Variable's name unambiguity
« Reply #7 on: November 22, 2018, 09:53:58 PM »
    Illustration for proposition. var0 is global of this module, and you can not give to local variables this name. var1 is local variable, but you can not define variable with this name in nested block. var1 and var2 are locals, so you can use these names in both functions.

    uint32 var0;

    fun
    proc0(){
        real64 var0; /* Error: name of variable is equal to global */
        byte var1; /* OK */

        do {
            char * var1; /* Error: name of variable is equal to previously defined local */
            uint16 var2; /* OK */
        } while(null);

        var2 = 33; /* Maybe, to allow it? */
    }

    fun
    proc1(){
        real32 var1; /* OK */
        utf8 * var2; /* OK */
    }

    I think, it will not strict programmer a much in choosing of names. Empty user's module have no globals at all - imported module's names are concentrated in (dot). You have all words of language for choosing names for your variables.
« Last Edit: November 22, 2018, 10:37:36 PM by acbaile »

acbaile

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: Variable's name unambiguity
« Reply #8 on: November 22, 2018, 10:09:46 PM »
    You introduced that order of functions in program is not important more. All functions of module are visible in any point. It's very convinient. Maybe, to do the same with local variables? Like in previous post. You defined variable in nested block, but you can access it from outside - in any point of function. You can access variable that is defined later, even in nested block.

    With strict rules of naming it will be unambiguously.

    I feel - it's cool idea :D .
« Last Edit: November 23, 2018, 11:17:10 AM by acbaile »