by roarcher 3 days ago

> it looks to me that the authors of those languages are parroting other languages rather than understanding the reason of those language choice.

I don't mean this to sound combative, but I think you are the one who doesn't understand the reason for the language choice. I assume you're objecting to the fact that these languages use different operators for module/namespace paths (`::`) and object member/method access (`.`), not the `::` symbol specifically.

You seem to assume that Rust blindly imitated C++, but that's not the case. The `::` syntax allows the compiler to identify and resolve all the static paths before any type inference or other analysis. This is important because macros are expanded between these stages, and can in turn introduce more static names which must also be resolved before any further compilation.

You might be able to introduce a rule that any `.`-path that can be resolved statically will be, trumping any non-static members (or maybe not, it might cause ambiguities I'm not thinking of), but Rust's stated design philosophy favors explicitness.

I don't know what this language's reason for using it was, as I don't see any mention of macros. But in general it simplifies compiler design. If you can resolve all the static names up front, the following compiler stages can ignore the concept of namespaces altogether.

kreco 3 days ago

I assumed Evergreen blindly imitated Rust.

However, I believe Rust purposely imitated C++, for reasons. And I still don't like it.

A lot of language are doing fine using dots. And if you are going to use '::' you can have your reasons. I would still find it annoying to type and read.

Just to add precision: I critic the syntax (which is very subjective), and I critic the parroting, as two separated arguments.

  • roarcher 3 days ago

    > A lot of language are doing fine using dots.

    I have implemented one such language, and while it is indeed doing fine, the dots-everywhere syntax really does complicate name resolution. It only uses it because the distinction between two different operators would be lost on its intended less-technical audience. It is a (in my opinion unfortunate) tradeoff made for a specific reason.

    And one thing those languages all (as far as I know) have in common is that they do not have Rust's macro system. It may well be impossible to implement that without a distinct operator.

    I have no opinion as to whether that operator should be `::` or some other arbitrary symbol, but I believe that no matter what symbol they chose, someone would complain that it doesn't fit their personal taste. Can't please everybody.

    • Joker_vD 2 days ago

      > I have implemented one such language, and while it is indeed doing fine, the dots-everywhere syntax really does complicate name resolution.

      Can you share an example? In my experience, this only happens with serious reuse of names across both types and values, e.g. with something like

          struct a { 
        struct x {
            typedef int y;
            y x;
        };

        struct y {
            typedef double x;
            x y;
        };

        static x y;
        y x;
    };


    a a;

      after which the unified syntax "a.x.y" could either mean a typedefed int from struct x, or a double field from struct y... but why would you even want to support such scenarios? C++, for example, prohibits namespaces from sharing the names with types and values in the same scope, and even though it uses "::" for namespace lookups, it still had to introduce "typename" keyword to explicitly disambiguate the type names from values anyhow so...