Comment by Lucasoato

3 days ago

> Mutability

> By default, variables are mutable. You can enable Immutable by Default mode using a directive.

> //> immutable-by-default

> var x = 10; > // x = 20; // Error: x is immutable

> var mut y = 10; > y = 20; // OK

Wait, but this means that if I’m reading somebody’s code, I won’t know if variables are mutable or not unless I read the whole file looking for such directive. Imagine if someone even defined custom directives, that doesn’t make it readable.

Given an option that is configurable, why would the default setting be the one that increases probability of errors?

For some niches the answer is "because the convenience is worth it" (e.g. game jams). But I personally think the error prone option should be opt in for such cases.

Or to be blunt: correctness should not be opt-in. It should be opt-out.

I have considered such a flag for my future language, which I named #explode-randomly-at-runtime ;)

  • > Or to be blunt: correctness should not be opt-in. It should be opt-out.

    One can perfectly fine write correct programs using mutable variables. It's not a security feature, it's a design decision.

    That being said, I agree with you that the author should decide if Zen-C should be either mutable or immutable by default, with special syntax for the other case. As it is now, it's confusing when reading code.

  • But why put it as a global metaswitcher instead of having different type infered from initial assignation qualifier?

    Example:

        let integer answer be 42 — this is a constant
        set integer temperature be 37.2 — this is a mutable
    
    

    Or with the more esoglyphomaniac fashion

        cst ↦ 123 // a constant is just a trivial map
        st ← 29.5 // initial assignment inferring float

  • > Given an option that is configurable, why would the default setting be the one that increases probability of errors?

    They're objecting to the "given", though. They didn't comment either way on what the default should be.

    Why should it be configurable? Who benefits from that? If it's to make it so people don't have to type "var mut" then replace that with something shorter!

    (Also neither one is more 'correct')

    • Well, arguably if it's immutable, then it's not a variable so "var" doesn't make sense. The corollary is if it's a variable it should be mutable so "var mut" is a tautology.

      I think "const x = something();" would be logical but they've used const already for compile-time constants. There's probably a sensible way of overloading that use though, depending if the expression would be constant at compile-time or not, but I've not considered it enough to think about edge cases (as it basically reduces to the halting problem unless any functions called are also explicitly marked up as compile time or not).

      1 reply →

Yeah, immutability should probably use a `let` keyword and compiler analysis should enforce value semantics on those declarations.

  • Agreed, using `var` keyword for something that is non-var-ying (aka immutable) is not very intuitive.

    • Mutability is distinct from variability. In Javascript only because it's a pretty widely known syntax:

          const f = (x) => {
            const y = x + 1;
            return y + 1;
          }
      

      y is an immutable variable. In f(3), y is 4, and in f(7), y is 8.

      I've only glanced at this Zen-C thing but I presume it's the same story.

      12 replies →

It's not ideal but it seems like something an LSP could tell you on a hover event. I didn't see an LSP (I didn't look that hard either) but presumably that's within the scope of their mission statement to deliver modern language ergonomics. (But I agree with sibling comments that this should be a keyword. Another decent alternative would be that it's only global in scope.)

Other languages also have non-local qays of influencing compiler behavior, for example attributes in rust (standard) or compiler pragmas in C (non-standard).

When reading working code, it doesn't matter whether the language mode allows variable reassignment. It only matters when you want to change it. And even then, the compiler will yell at you when you do the wrong thing. Testing it out is probably much faster than searching the codebase for a directive. It doesn't seem like a big deal to me.