4 ms·

I find it disconcerting that the go compiler is such a mess that it took this much effort just to alias a new keyword. I know the Ruby internals are famously v

• philosopher1234 5y ago
  Why does this mean its a mess? Why should the codebase be optimized for adding new keywords, when that happens maybe once a decade? Your comment seems overly negative.
  • benhoyt 5y ago
    Indeed. In fact, even with the release of generics in Go 1.18, which is coming out in early 2022 exactly a decade after Go 1.0, there will be no new keywords. So it won't even have happened once in a decade. :-)
• throwaway894345 5y ago
  What's a language that allows for easily adding new keywords? What tradeoffs were involved in facilitating that property? Is this property compatible with Go's goals?
  • wk_end 5y ago
    In this context (I see you Lispers) the difficulty of adding a new keyword to the compiler is less a property of the language than a property of how the compiler's implemented. Specifically, the weird stuff the author encountered like: * Generating the token list by parsing the comments of a source file * only parsing up to a hard-coded token instead of all of the known tokens (?!) * using a hacky token hashing mechanism that only looks at the first two characters of the token have nothing to do with Go-the-language.
    • preseinger 5y ago
      A language and its principal compiler are I think not so decoupled as you're implying.
      • taeric 5y ago
        There was a callout to lisp. Common Lisp, in particular, is implemented in an amusingly large number of ways. I think this used to be more true for all languages? Getting defined by the common implementation is something that feels more true today.
        • preseinger 5y ago
          I suppose my claim is that truly pragmatic languages can't afford to maintain as strict a separation between spec and implementation as e.g. Common Lisp does. And I guess also that this isn't something to feel bad about!
          • taeric 5y ago
            I fully agree that this is nothing to feel bad about. It probably isn't as hard as it sounds, though.
      • wk_end 5y ago
        That may be the case in the abstract, but I'm not really talking about the abstract, and I'm not really trying to imply anything...except maybe that the Go compiler could be written in a friendlier and easier-to-modify way, possibly at some performance cost (which might not be worth it!). That is, is there a particular quality of the Go language you can think of that necessitates only looking at the first two characters of tokens when hashing? Or that requires it to iterate only to `_Var` when generating the keyword map instead of the full length of the list?
  • nikanj 5y ago
    Many languages are easy and fast to extend. Namely toy languages that are not really going anywhere. A dead-simple, easy-to-extend compiler is a few thousand LOC - and produces completely crap code for all platforms. If you want your language to actually have some real-world usage, you need real-world performance numbers. Which tends to lead to compiler codebases an few orders of magnitude larger, and much gnarlier to extend.
    • adgjlsfhk1 5y ago
      Also, good languages don't have many keywords, so they aren't optimized for adding them.
      • tester756 5y ago
        idk whats your definition of good lang, but C# has shitton of keywords https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/ https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
        • preseinger 5y ago
          > C# has shitton of keywords To it's detriment, I guess.
        • adgjlsfhk1 5y ago
          Of that list, if C# were a more powerful language, I don't think the following would need to. bool char decimal double enum false fixed float in int lock long new null ref short sizeof string true uint ulong