3 ms·

Theyre going to change the whole backend essentially just for better not nil and static array bounds checking?

• zem 3y ago
  that "just" strongly underestimates the value add of those two features!
  • unclad5968 3y ago
    The features already exist and the topic doesn't indicate how they would get any better.
• hashtag-til 3y ago
  Having a structured IR could make it pluggable to the MLIR ecosystem, for example.
  • mathisfun123 3y ago
    Just because it has IR in the name doesn't mean there's any connection. If you want to emit MLIR using nim you can already do this using MLIR's C API, if you want to map nim ast to to existing MLIR IR you can already do this if you provide the necessary control flow analysis, if you want to map nim ir to MLIR you will still need a lowering or nim dialect.
• red_vodka 3y ago
  The mention of making CPS (continuous passing style) compiler integration possible is something very important. That would enable Go- or Kotlin-like coroutines to land in the language, which is sorely needed to end the async wars between stdlib's horrible asyncdispatch module, and Status.im's barely documented Chronos async/await implementation.
  • throwmeouthn 3y ago
    [dead]
  • zevv 3y ago
    There has been a more-or-less working CPS implementation for Nim for a few years now: https://github.com/nim-works/cps https://github.com/nim-works/cps https://github.com/nim-works/cps/tree/master/docs https://github.com/nim-works/cps/tree/master/docs Nobody seems to care though, as it has gained no traction at all and it has been mostly ignored by the core team.
    • red_vodka 3y ago
      The issue with the CPS implementation here is that the compile times are too slow, and there are several restrictions due to flaws and limitations of the compiler. That's the reason CPS in the compiler is a big deal. I've used the CPS lib you're showing before, and it's very nice, but the compile times make it absolutely useless for productive development.