4 ms·
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 compile
by 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 agoA language and its principal compiler are I think not so decoupled as you're implying.
- taeric 5y agoThere 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 agoI 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 agoI fully agree that this is nothing to feel bad about. It probably isn't as hard as it sounds, though.
- wk_end 5y agoThat 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?