A heardoc-like block for splitting single line pipelines into readable multiline code

[lmorg]

I have an idea, and it might be a bad one, but presently if we want to span a command line over multiple lines we have to terminate each line with \ for example:

open https://api.github.com/repos/lmorg/murex/issues \
    -> foreach issue { out "$issue.number: $issue.title"} \
    -> head -n 10

It's ugly, easy to forget and fiddly to make changes to.

So I'm proposing a block token: {+ and +}. For example

open https://api.github.com/repos/lmorg/murex/issues {+
    -> foreach issue { out "$issue.number: $issue.title"}
    -> head -n 10
+}

This would also work for single commands that take a lot of parameters, eg

find . {+
    -type  f
    -name  foobar
    -atime 7d
+}

The basic premise of {+/+} would be that it converts \n to \s for commands and parameters.

The key question here is this: would this feature...

1. enhance the language?
2. confuse new users?
3. or niether, it just adds bloat?

[JeffMelton]

Hm… I don't use multiline commands much in other shells, but some of that is because of the issues you pointed out. The backslash is used widely, though, so if I were just trying out the language for the first time, I would almost certainly try that first and be confused and/or annoyed by the shell not aligning with my expectation. PowerShell's backtick annoys me every time I need to use it, for example.

What if a pipe followed by a newline was understood by the readline as a soft return? That wouldn't cover the case of a lot of flags, but it's intuitive (to me), and it doesn't require extra keystrokes or remembering which incantation to use.

[lmorg]

The backslash method does work in Murex too, eg

open https://api.github.com/repos/lmorg/murex/issues \
    -> foreach issue { out "$issue.number: $issue.title"} \
    -> head -n 10

Where this falls down was if you were to want additional line spaces, eg

example parameters \
    -> example parameters \
    \
    \ # A comment grouping a couple of commands in the same pipeline
    -> example parameters \
    -> example parameters

which could be more neatly written as:

example parameters {+
    -> example parameters
  
    # A comment grouping a couple of commands in the same pipeline
    -> example parameters
    -> example parameters
+}

...but I'll be the first to admit this is an extreme edge case. Its usefulness is probably more around writing self-documenting code than it is for day-to-day scripts.

What if a pipe followed by a newline was understood by the readline as a soft return? That wouldn't cover the case of a lot of flags, but it's intuitive (to me), and it doesn't require extra keystrokes or remembering which incantation to use.

Early versions of Murex did support this but it was removed when the parser was completely rewritten. I've noticed a few other modern shells support this pattern too.

I'm not against that feature but it does have a few drawbacks:

1. it only works where the join is between commands, eg using ||, &&, -> tokens to denote a continuation. Which means if you want to break a command's parameters across multiple lines then you need to fallback to escaping the new line
2. Murex already uses commands invoked by a pipe inside functions as a lazy syntax for reading from stdin (eg function count_foobar { -> regexp f/foobar/ -> count })
3. there is the potential for more edge case bugs with specific command joiners either expectedly, or unexpectedly handling new lines
4. this wouldn't be supported in the REPL because code is expected to execute upon [RETURN] unless the there are missing closing brackets or quotation marks. Which means you couldn't copy/paste code into the REPL if it uses this type of line continuations

Albeit I can think of strong arguments to counter those drawbacks:

1. this is admittedly another edge case. There is an experimental command I'm working on at present that could make use of {+ / +} feature but i could also solve that problem differently too. So is this a serious enough concern to justify adding more complexity to the language?
2. The <stdin> -> command pattern is recommended anyway. And you'd only use -> command syntax if the stdin read was the first task of the function, which a line continuation wouldn't be. So, arguably, the stdin and line continuation features could work together without any issues
3. this is really more of an argument around having good unit tests and documentation
4. this is possibly the only deal breaker. I could rewrite the REPL to better support multi-line pastes so that that line continuations work without an escape, but is the effort worth the reward?