6 ms·

Need this for every language …

• kccqzy 1y ago
  It can't. It uses ownership types in Rust to do the analysis. It can be fooled by Rust's interior mutability. Other languages don't have a type system that enables this.
  • eru 1y ago
    You merely explain why you can't copy the implementation strategy. But that says nothing about providing the same value to the user in other languages via different means.
    • kccqzy 1y ago
      You merely assume an alternative implementation strategy exists and that it provides the same value to the user. But that says nothing about whether it actually can exist.
      • eru 1y ago
        > You merely assume an alternative implementation strategy exists [...] Huh, where am I making that assumption? > But that says nothing about whether it actually can exist. Yes, I expressed no opinion on that.
        • throw10920 1y ago
          > Huh, where am I making that assumption? You didn't, and you didn't express any opinion on whether or not it can exist, either - GP is arguing dishonestly to shill Rust.
          • eru 1y ago
            Which is really a shame. Rust is a nice enough language that it doesn't need dishonest shilling.
  • ffsm8 1y ago
    From thinking about it and merely looking at the gif example... I think you could actually get there via language server alone - at least mostly? It just highlights parts that interface with a symbol, right? And that's information the language server is supposed to expose. You'd "just" have to make a x+1 mapping to highlight anything that's touching the symbol To be clear, I'm just speculating here and not speaking with authority on the topic. It's possible I'm missing something which makes this approach infeasible in practice
    • deleted 1y ago
      [deleted]
  • yread 1y ago
    Shouldn't be too difficult for C# with Roslyn
    • animal531 1y ago
      Visual Studio is irritatingly doing the opposite. If it detects unused methods/variables it will make them darker (which in general is quite useful), but it also does so when you're still busy creating new methods and just haven't linked them to anything yet.
  • cma 1y ago
    LLMs are getting better and cheaper. It's ridiculous overkill for the task, but they could potentially do something like this and more sophisticated versions highlighting related code on other dimensions.
    • bayindirh 1y ago
      Programming languages are built upon mathematically defined and deterministic syntax. You can analyze them with formulae, take concrete and deterministic actions on the syntax tree. There's no need to unleash a fuzzy and inefficient network on something designed to be deterministic and parseable.
      • cma 1y ago
        Yes but he was saying other languages weren't in this aspect. And I said the same as you but that also it could highlight on more abstract things that aren't in the parse tree, I meant things like feature-relatedness etc. These variables are only used for intermediate logging stuff and get greyed out etc.
      • eru 1y ago
        It's not so much syntax as semantics here. And programming languages are often described and implemented with rather vaguer ideas than fully formally specified semantics. (Even Haskell doesn't have fully formalised semantics.)
  • bayindirh 1y ago
    If Eclipse's archaic(!) variable renaming feature for C++ can distinguish between related and unrelated variables which have the same name, you can implement this thing in almost any language. Eclipse CDT has a real-time static analyzer for the code you're working on though. It's not as naive as it looks from a distance.
    • kccqzy 1y ago
      Consider this simple C code: void inc(int* a, int* b) { *a += 1; *b += 2; } Are you adding one to an integer and adding two to another integer, or are you adding three to a single integer? In other words are the two pointers actually pointing to the same variable? There's no way to know. When you select one pointer, should the other also be highlighted? But in Rust you cannot have two mutable references to a single variable so the above cannot happen. Variable renaming is a much much simpler task than this. Of course it is archaic and has existed for a long time.
      • cowboylowrez 1y ago
        honestly I'd be ok with a being treated as different than b in this colorized use case. sure, maybe it'd be "bug inducing" or be a subconcious push toward human brains to forget they produced two aliases etc but I think what you're proposing with the c colorizing is impractical and yes I get it, "the tools caused the crash that brought down civilization" but c'mon, if you're still using c, folks have already talked you out of safety nets lol
      • throw10920 1y ago
        > In other words are the two pointers actually pointing to the same variable? This statement is incorrect. You can't have pointers to a variable. You can have pointers to a memory address, and most people would be fine with a tool that is correct up to the level of being unable to differentiate that. This is a disingenuous redefinition of what the GP is looking for in order to shill Rust.
  • ndriscoll 1y ago
    It's not exactly rare to avoid mutability/use a functional style in application code, and even in mutable code, IME aliasing is rare. In some ways Rust's rules are kind of a formalization of what was already good practice in C. Variable scope is also usually small. Turns out things that are easier for the computer to analyze are also easier for people to analyze, so it's long been good practice to structure your code in easy to analyze ways.