trplkt should be featureful while remaining comprehensible and small.
The following soft limits should be taken into consideration when extending the language:
The size of the lexer should not exceed 1 KLOC. It is currently ~750 LOC and solves essentially all anticipated needs for the foreseeable future.
The parser should aim to stay under 2.5 KLOC or so. It is currently around the same size as the lexer (smaller, actually, with a couple hundred lines for both IR forms), but the parser is not a "total" parser—it doesn't fully validate the input against a well-defined grammar (because the grammar has yet to be defined in a concrete form)—so it is expected to grow substantially. We *do* want high-quality error reporting, but this should not be at odds with our desire to keep the parser small. It should be possible to achieve friendly error output without completely entangling the parser implementation with such concerns. I've already started filling out a `NiceErrors` module, but there's no reason that this should necessarily contain all things related to errors and error recovery, so long as a reasonable separation is maintained between the parser's happy (and hot) path versus the path that involves error reporting.
One concern about "comprehensible" involves involves the comprehensibility of a program to other machines. Our foremost concern is to define a grammar which (a) yields programs that can be readily executed by ordinary people, even under less-than-favorable (or downright adversarial, even) conditions, and (b) that as many people as possible can make sense of the program implementation. A "secondary" concern, which actually isn't so secondary, since it feeds back into the primary concern, is that machines are able to make sense of the same programs. This demands a language that lends itself to static analysis (even at the expense of "expressivity" for the program author). The feedback occurs when a person who is otherwise unable to make sense of a program can in turn feed that program into another program that can help illuminate the the inner workings of the input program. (It is anticipated that this is a limit that will be seen as overly restrictive. It's a topic worthy of discussion all its own, but it should be pointed out that if it's possible for programs to be understood by machines, then it's also for machines to make the act of editing the programs easier. People attracted to metaprogramming should find this to be enticing, and not a turn off...)