On 27/11/2014, M Farkas-Dyck <strake...@gmail.com> wrote: > • Unambiguous grammar > • Low level > • Tuples > • Easy interface with C
Forgot one: • Free declaration order On 27/11/2014, Troels Henriksen <at...@sigkill.dk> wrote: > The only implementation seems to be written in a pretty atrocious style: > https://github.com/strake/pkc/blob/master/CodeGen/Common.hs Yeah, it is messy. Alas, code alignment means messy diffs when one modifies that alignment, so it's a choice of evils. Perhaps I chose poorly. > Also - why care about whether or not the grammar is simple to parse if > you're using something like Haskell to implement it, which can easily > handle very context-dependent grammars? Not as easily as a parser generator with a context-free grammar. I'm not against context-sensitivity per se but C's is wanton. > I'm curious about which flaws of C you are trying to fix. Sure, the > syntax is simplified, and maybe the built-in numeric types are a little > saner, but the benefit of such seems low compare to the cost of using > such an obscure language. The biggest one is tuples. > If you really want to substantially improve on C, I think adding a more > elaborate type system, with which you can encode more invariants without > run-time cost, is a more interesting approach, which can be seen in > e.g. Rust. Yes, such compiler-checked invariants are interesting, and potentially winning, but beyond the scope of K for now at least. > This will cost you greatly in increased implementation > complexity, which I think is not to the taste of many on this list. > Most of the complexity in a minimal C compiler will be in the parser, > for example. Which shows why parsibility is careworthy ☺
