kona
kona copied to clipboard
kevinlawler
other languages
As demonstrated by Kx, an important aspect of the power of K is the ability to implement other REPL languages using K (the Q language being an example). How would someone use Kona to implement a different language?
If one of the IO verbs had an overload equivalent to performing a readline() from stdin and returning a character vector it would be possible to implement any kind of REPL or interactive CLI that was desired. A more general approach might allow a user to specify a delimiter, but breaking on a newline seems like it would cover the most common cases. There are examples of parsers written in K, so I don't think any additional language-level support is needed.
Is there an existing IO verb which could be sensibly overloaded in this fashion, and if not is there any preference for which number to use for a new one? 7: appears to be the first free number.
I am not yet convinced this is the right idea for writing an interpreter in K. Typically a parse or even a token may continue over multiple lines (think string). In K "\n" is equivalent to ";" so you can trivially define a multi line expression.
If you read in a line, even the scanner will have to maintain state because a) there may only be a partial parse by end of a line and b) another top level expression may start on the same line. Also consider that there may be an embedded \n in a string or a comment. Finally consider that part of the line may be input to the expression being evaluated as in Scheme:
> (read)foo
foo
Here the Scheme REPL doesn't eat up foo so (read) gets to use it as its own input.
I think you'd likely need a buffered character by character input with even an ungetc() to put back a lookahead char!
In any case I would suggest playing with the idea in a separate branch and implement a parser or two to get a feel for it. If the idea pans out it can be merged in the head branch. Also, if done right, the same idea can be used for K's own REPL!
Now if you just want to read in line at a time for whatever purpose, that is a separate issue.
K is a small language so in my opinion we should be conservative in adding new facilities in the base interpreter. You can always link in C code for a specific application.
See the cK language written in K.
http://www.nsl.com/papers/ck.htm
http://www.nsl.com/k/ck.k