Skip to content
This repository has been archived by the owner on Dec 27, 2022. It is now read-only.

Sub-invocations ((...)) #4

Open
pfrazee opened this issue Nov 18, 2019 · 4 comments
Open

Sub-invocations ((...)) #4

pfrazee opened this issue Nov 18, 2019 · 4 comments

Comments

@pfrazee
Copy link
Member

pfrazee commented Nov 18, 2019

Sub-invocations are a way to compose multiple command invocations by passing the output of one command into the switch-value or argument of another command.

Sub-invocations are wrapped in parenthesis ( ... ).

Example passing the result as an argument:

some-cmd (other-cmd)

Example passing the result as a switch-value:

some-cmd --switch (other-cmd)

The sub-invocations form a tree of invocations. For instance, the following example:

a (b (c) (d)) (e (f (g)))

Would form the following tree:

  • a
    • b
      • c
      • d
    • e
      • f
        • g

The invocations are executed depth-first from left to right. Therefore the execution order of this tree would be:

  1. c
  2. d
  3. b
  4. g
  5. f
  6. e
  7. a
@matthewauld
Copy link

matthewauld commented Jun 18, 2020

Ah, this is way more flexible than "then/catch".

The only downside is that is it written the opposite way people usually think. If you want to "read a list of objects from a filename, pull out the ones that have a property x greater than four and print it to the screen, you need to write echo (filter "x>4" (readFile filename 'json'))) as opposed to readFile filename 'json' then filter "x>4" then echo. I think that is why the unix | works the way it does. Also the ability to press "up" and get the previous command and just tack more on the end of the previous command if you don't like the output.

But then you loose the flexibility of being able to pass output to different arguments. Which is really nice.

@matthewauld
Copy link

Or... You could do both? echo (readfile filename 'json' then filter "x>4") is not horribly unreadable. Thinking out loud here.

@pfrazee
Copy link
Member Author

pfrazee commented Jun 18, 2020

Yeah like you say, the trouble with stdio / piping is that it's a separate channel than the arguments and return value, so it complicates our programming model. That said, it's always possible that we making the piping model work as a syntax variation of sub-invocations, so:

echo (filter "x>4" (cat foo.json)))

could be rewritten as

cat foo.json | filter "x>4" | echo

And it would send the return value into the last unfilled argument, which is implicitly:

cat foo.json | filter "x>4" HERE | echo HERE

@matthewauld
Copy link

Yeah - it might be a nice shorthand to have - and it would still maintain the functional programming style.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants