[snapdangle]

True but if I understand correctly (and I'd be happy to be corrected by someone with more K experience), the smaller size of input data should also have an impact on real world parser performance (including the memory usage involved therein).

[dan-robertson]

Any sane interpreter would parse things beforehand and so you shouldn’t expect a significant fraction of performance to be parsing dependent for anything except a trivially sized dataset. Two reasons to care a lot about parsing performance:

1. Silly reasons mean that you need to block while you parse and reducing this blocking time is important (eg JavaScript. One trick is to optimistically assume that the script won’t do a document.write and try to process the html after it. Another would be to eg only parse enough of a function definition to find out where it ends and only parse it more (or block on parsing it) if it gets called)

2. You get a large amount of source code that needs to be quickly parsed all at once to be interactive (eg JavaScript and booted web pages)

I think in the case of k you only parse a small amount at a time in interactive use and any non interactive use would be for a big enough job (yet still generally small enough program) that parsing time would not be significant.

If parsing efficiency really mattered, surely the language would use something easier to parse (eg something rpn based to avoid parens, using single characters for each operator and just disallowing variable names from containing those characters).

In summary: I think parsing speed is basically irrelevant to whether k is fast or not, so long as the parser is reasonably fast, it’s efficiency shouldn’t be a constraint on the language.