Closed ab5tract closed 4 years ago
This is a good idea, but it needs a tweak- the IO verbs available in the CLI frontend are slightly different, and this should be reflected in the "System" section. See: https://github.com/JohnEarnest/ok/blob/gh-pages/repl.js#L9-L45
I see that you've already made the necessary changes to reflect the differences in available "backslash commands".
Great point! I'm still very new to K (and mostly been learning Q so far), so please bear with me here.
The primary differences that I can tell regarding the system functions in the CLI version is that 0
deals with file names (provided as strings). 5
seems to act the same.
However, I can't seem to get 1
to operate on file names the same way that the HTML version works on URLs.
~/c/k/ok> echo "{\"fruit\":\"apple\"}" > /tmp/foo.json
~/c/k/ok> node repl.js
oK v0.1 (inspired by K5: http://kparc.com/k.txt; \h for help)
1: "/tmp/foo.json"
invalid arguments to 1:
In the CLI frontend there is no implementation of 1:
; only 0:
and 5:
. 0:
behaves like it would in k2/k3:
The monadic form of 0:
reads data from a path, given as a symbol or string. If the path is the empty symbol (`
) it is interpreted as stdin. Due to limitations of node itself, reading from stdin is only allowed if you're running a script, and not the REPL. If the path is a file, the lines of that file are loaded as a list of strings, and if the path is a directory, the contents of that directory is enumerated as a list of strings.
Dyadic 0:
Writes some value (the right argument)- which should be a string or list of strings- to a path (the left argument), which works analagously to the monadic case. The empty symbol means print to stdout.
5:
is identical between the browser and CLI frontend: it just casts a K value to a string representation of that value.
It also looks like you've (accidentally?) removed the description of the backslash commands which are exclusive to the web REPL from that reference card. I think those should be restored.
Ah, it does look like I messed that up, will fix that.
Regarding 1:
in the CLI frontend: should it fail instead of complaining about invalid arguments?
Well, it's not wrong; "invalid arguments to ___" is the error message oK gives for all verbs that do not have an entry in the appropriate slot for the dispatch table.
The oK interpreter itself defines no IO verbs at all; it just reserves empty slots for them. Each frontend is responsible for registering implementations for any slots that they wish to populate.
I suppose there's always room for improving error messages.
Well, it's not wrong; "invalid arguments to ___" is the error message oK gives for all verbs that do not have an entry in the appropriate slot for the dispatch table.
The oK interpreter itself defines no IO verbs at all; it just reserves empty slots for them. Each frontend is responsible for registering implementations for any slots that they wish to populate.
I suppose there's always room for improving error messages.
Ah, this is very interesting! Now that you point it out, it's quite simple. I was really trying to understand if there was something more clever going on with the code than what I was reading (ie, logic in the parser/interpreter/etc) but in fact it seems I can trust my instincts in this code base.
I guess my only concern in this case is the disparity between interfaces -- a newbie like me could end up tearing out hear trying to understand why the otherwise valid syntax is giving an invalid argument error.
I guess it's kind of like the \h
option. I left it out of the info card because, well, it's a bit redundant info at that point! Likewise, if people follow the card they will know that there is no 1:
available.
Not a blocker on this topic, at any rate.
OK, these changes look reasonable. Thanks.
I noticed that there was some important information available in the web version that wasn't in the CLI repl.
Also thought it might be helpful to let the user know about the syntax help via the initial line from oK.
Very cool project by the way!