31–39 of 39 posts
Question: Does the postfix notation allow you to chain commands together that in bash would have to be nested in brackets, like actual postfix math?
So for example, rather than the infix need of brackets to resolve ambiguity in this expression ((1 + 2) * 3) = 9, postfix just writes it like this: 1 2 + 3 * = 9.
I'm really intrigued by this, because I like postfix notation and would love to be able to work more with in. Unfortunately, I only somewhat understand the examples! Question: Does the postfix notation allow you to chain commands together that in bash would have to be nested in brackets, like actual postfix math? So for example, rather than the infix need of brackets to resolve ambiguity in this expression ((1 + 2) *…
1 2 +; 3 *
Earlier quoted context omitted.
Even after perusing jq's manual multiple times and having written several complex incantations, I still have no idea how to properly combine `|` and `.[]` except by trial and error, or why `select()` needs to be used inside `map(select(...))` Recently I needed to extract some data, and after fighting with jq and its manual for half an hour, I solved the problem in 30 seconds with node.js I appreciate the idea behind…
Some nice alternatives for querying JSON via CLI include jello, yamlpath, and dasel.
Seems interesting, but I’m already lost at the first example: lsr; [test m] grep; [f I’m guessing the lsr is a recursive ls, and presumably map is a HOF (functional) map. I know what grep means. So that means “test” and “data” are strings, and I have no idea what “m” is for. And “f Perhaps it’s more parseable to someone who speaks lisp, but I still think not having clear (simple) examples is a nonstarter for a projec…
The 'sh' command that it corresponds to is above it: find . -iname '*test*' -print0 | xargs -0 grep data but possibly a bad assumption on my part that the mapping was clear. In any event, 'm' is for regex string matching, and 'f<' is for reading a file into a generator (basically an iterator over the lines in the file). It's a good point that more, simpler examples would help.
That said, the examples could be better explained just like you did here now. The examples are not bad but things like the f iterator probably needs some explaining.
I really like the idea. A more simple shell language is something I've wanted. Either lisp or forth would work but the basic issue is that bash and the rest are so complicated and with so many special things you have to know. Doing anything other than most basic shell scripts is horrible.
Earlier quoted context omitted.
Even after perusing jq's manual multiple times and having written several complex incantations, I still have no idea how to properly combine `|` and `.[]` except by trial and error, or why `select()` needs to be used inside `map(select(...))` Recently I needed to extract some data, and after fighting with jq and its manual for half an hour, I solved the problem in 30 seconds with node.js I appreciate the idea behind…
Some nice alternatives for querying JSON via CLI include jello, yamlpath, and dasel.
Earlier quoted context omitted.
Because that's the very definition of a concatenative language.
I don't think that there's anything inherent about concatenative languages that forces them to be postfix. The Wikipedia definition (not authoritative, surely, but one we can all access) is: > A concatenative programming language is a point-free computer programming language in which all expressions denote functions, and the juxtaposition of expressions denotes function composition. As long as all functions are fixed…
Earlier quoted context omitted.
The 'sh' command that it corresponds to is above it: find . -iname '*test*' -print0 | xargs -0 grep data but possibly a bad assumption on my part that the mapping was clear. In any event, 'm' is for regex string matching, and 'f<' is for reading a file into a generator (basically an iterator over the lines in the file). It's a good point that more, simpler examples would help.
The examples in the README are really not the best. Anyway, given from the examples for me this reads as a language to write hacky onliners of code which are probably easy to write once but hard to read anytime after. One moment... we had such a language in the past: Perl! :-D Perl5 onliners were infamous for their expressive power but sometimes crazy to understand even if you thought you were fluent in perl ;-)
There is definitely a 'write-only' angle to concatenative (postfix) languages that rely on a stack. I think this type of language/approach is uniquely well-suited to this use case, though, where the focus is interactive use, plus short programs that are not generally intended for distribution, since you get the most out of the advantages around conciseness, without incurring the costs that come with larger programs.
Earlier quoted context omitted.
The 'sh' command that it corresponds to is above it: find . -iname '*test*' -print0 | xargs -0 grep data but possibly a bad assumption on my part that the mapping was clear. In any event, 'm' is for regex string matching, and 'f<' is for reading a file into a generator (basically an iterator over the lines in the file). It's a good point that more, simpler examples would help.
Don't listen to most of the people here. Perl? What are they talking about. It is a concatenative shell. Think forth. That said, the examples could be better explained just like you did here now. The examples are not bad but things like the f iterator probably needs some explaining. I really like the idea. A more simple shell language is something I've wanted. Either lisp or forth would work but the basic issue is th…
Thanks, the readme has been expanded now so that it has better examples, and the full documentation (https://github.com/tomhrr/cosh/blob/main/doc/all.md) is more clearly marked for those who are looking for more detail.
The elephant in the room for me is that > implemented as functions that return first-class values, as opposed to relying on executables that return text streams. This makes working with the results simpler Is explicitly disregarding several Unix philosophies, but not really discussing why the author believes those philosophies are wrong. It proceeds to produce code without the (at least in my view) nice properties of…
> Is explicitly disregarding several Unix philosophies, but not really discussing why the author believes those philosophies are wrong. I'm not sure I'd characterise these parts of the Unix philosophy as 'wrong'. For example, if you are writing a shell program for use by somebody else, then having that program work with text streams makes sense. The focus here is interactive use and short functions/programs for local…