@dgl I've been doing a bunch of thinking on your "shells should have json as a first class citizen" thing.
I want to follow the "shape" of rc(1) which had lists as a first class type. So extending that to objects can't be that hard, right?
@dgl Some decisions:
* () Is used for grouping commands (instead of {} in rc) this leaving {} free for objects. Use [] for lists (instead of () for rc).
* Use $foo[name] to make it possible to use $foo[$bar[baz]] and $foo[$bar][baz] (instead of $foo.$bar.baz which is ambiguous).
* (Optionally) require , between items in [] lists.
* Support multidimensional ifs splitting.
* Extend rc ^ to support mapping a function (to allow mapping over an object's key/vales)
@dgl one thing that I am not particularly happy about is using `(command) to support inclusion.
What type should the output be? rc used ifs (the only place ifs is used) to split into words which were then used in a list. sh obviously transcludes it as a string then reparses.
My thought is to keep the rc behaviour. But allow `J(command) to parse the output of command as json. This seems like a bit of a hack. It does mean I could have other parse types in the future (csv? XML?)
@robryk @dgl `[$nul](find . -print0) should dtrt as I'm not using nul terminated strings.
(A list between ` and () is the ifs override for this parse).
But yes, this is a very good point. I should have a test that this works.