On 27/11/2014, M Farkas-Dyck <strake888_AT_gmail.com> wrote:
> • Unambiguous grammar
> • Low level
> • Tuples
> • Easy interface with C
Forgot one:
• Free declaration order
On 27/11/2014, Troels Henriksen <athas_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 ☺
Received on Fri Nov 28 2014 - 05:33:32 CET