Re: [dev] K, a low-level procedural imperative programming language

From: M Farkas-Dyck <strake888_AT_gmail.com>
Date: Thu, 27 Nov 2014 23:33:32 -0500

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

This archive was generated by hypermail 2.3.0 : Fri Nov 28 2014 - 05:36:08 CET