feat: Implement fallback chain #302

pastor commented 2026年07月08日 11:24:07 +02:00

This change introduces a new type of separator for chaining commands on the BLUE
CLI. The idea is to be able to express fallback chains so if the main operation
fails there is a way to run an alternative chain of commands.

Here are some examples:

SEXP: (and (or build repl) dist)
CLI: $ blue build , repl -- dist

SEXP: (or (and configure build) (and help repl))
CLI: $ blue configure -- build , help -- repl

SEXP: (or (and configure build) (and clean build) report-bug repl)
CLI: $ blue configure -- build , clean -- build , report-bug , repl

• blue/ui.scm (load-blueprint-and-execute-commands): Handle fallback chaining.
  (entrypoint%): Pass chain pipeline.
  (chain-separator, fallback-separator): New variable.
  (separator?): New procedure.
  (parse-commands-arguments): Parse pipeline.
  (parse-arguments): Pass chain pipeline.

Fix: #280

This change introduces a new type of separator for chaining commands on the BLUE CLI. The idea is to be able to express fallback chains so if the main operation fails there is a way to run an alternative chain of commands. Here are some examples: SEXP: (and (or build repl) dist) CLI: $ blue build , repl -- dist SEXP: (or (and configure build) (and help repl)) CLI: $ blue configure -- build , help -- repl SEXP: (or (and configure build) (and clean build) report-bug repl) CLI: $ blue configure -- build , clean -- build , report-bug , repl * blue/ui.scm (load-blueprint-and-execute-commands): Handle fallback chaining. (entrypoint%): Pass chain pipeline. (chain-separator, fallback-separator): New variable. (separator?): New procedure. (parse-commands-arguments): Parse pipeline. (parse-arguments): Pass chain pipeline. Fix: #280

pastor commented 2026年07月08日 11:25:53 +02:00

@old I realized that the suggestion we had for implementing the pipeline using the -> is not possible since the bash lexer will pickup > as a redirection. I went ahead and used , as the fallback operator.

What do you think?

Also, we should probably add some tests for the new operator.

@old I realized that the suggestion we had for implementing the pipeline using the `->` is not possible since the bash lexer will pickup `>` as a redirection. I went ahead and used `,` as the fallback operator. What do you think? Also, we should probably add some tests for the new operator.

old commented 2026年07月08日 17:00:51 +02:00

SEXP: (and (or build repl) dist)
CLI: $ blue build , repl -- dist
SEXP: (or (and configure build) (and help repl))
CLI: $ blue configure -- build , help -- repl
SEXP: (or (and configure build) (and clean build) report-bug repl)
CLI: $ blue configure -- build , clean -- build , report-bug , repl

These are wrong I think. Here:

# Expect (true false)
$ blue true , false -- false
;;; (true)
# Expect (false true true)
$ blue false -- false , true -- true
;;; (false)
# Expect (false false true)
$ blue false -- false , false -- false , true , false 
;;; (false)

diff --git a/blueprint.scm b/blueprint.scm
index 093c3fa..1c767a8 100644
--- a/blueprint.scm
+++ b/blueprint.scm
@@ -35,8 +35,20 @@ (define blue-configuration
 (configuration
 (variables blue-variables)))
 
+(define-command (true args)
+ ((invoke "true"))
+ (pk 'true)
+ #t)
+
+(define-command (false args)
+ ((invoke "false"))
+ (pk 'false)
+ #f)
+
 (define blue-commands
 (list
+ true
+ false
 check-install-command
 coverage-command
 install-command

You can't express tree like logic with this. Threading logic sure.

> SEXP: (and (or build repl) dist) CLI: $ blue build , repl -- dist SEXP: (or (and configure build) (and help repl)) CLI: $ blue configure -- build , help -- repl SEXP: (or (and configure build) (and clean build) report-bug repl) CLI: $ blue configure -- build , clean -- build , report-bug , repl These are wrong I think. Here: ``` # Expect (true false) $ blue true , false -- false ;;; (true) # Expect (false true true) $ blue false -- false , true -- true ;;; (false) # Expect (false false true) $ blue false -- false , false -- false , true , false ;;; (false) ``` ```diff diff --git a/blueprint.scm b/blueprint.scm index 093c3fa..1c767a8 100644 --- a/blueprint.scm +++ b/blueprint.scm @@ -35,8 +35,20 @@ (define blue-configuration (configuration (variables blue-variables))) +(define-command (true args) + ((invoke "true")) + (pk 'true) + #t) + +(define-command (false args) + ((invoke "false")) + (pk 'false) + #f) + (define blue-commands (list + true + false check-install-command coverage-command install-command ``` You can't express tree like logic with this. Threading logic sure.

old commented 2026年07月08日 17:02:36 +02:00

@pastor wrote in #302 (comment):

@old I realized that the suggestion we had for implementing the pipeline using the -> is not possible since the bash lexer will pickup > as a redirection. I went ahead and used , as the fallback operator.

What do you think?

Also, we should probably add some tests for the new operator.

, is a valid separator for commands. blue foo --option=foo,bar. -- is known to be an invalid token in command line parsing so it is fine to use it.

@pastor wrote in https://codeberg.org/lapislazuli/blue/pulls/302#issuecomment-18786797: > @old I realized that the suggestion we had for implementing the pipeline using the `->` is not possible since the bash lexer will pickup `>` as a redirection. I went ahead and used `,` as the fallback operator. > > What do you think? > > Also, we should probably add some tests for the new operator. `,` is a valid separator for commands. `blue foo --option=foo,bar`. `--` is known to be an invalid token in command line parsing so it is fine to use it.

pastor commented 2026年07月09日 11:12:24 +02:00

@old wrote in #302 (comment):

blue false -- false , true -- true

I think we are looking at different goals here. It seems we didn't wrote it down, but, if I recall correctly, we decided not to support a complete tree as it would make the CLI usage a bit uncomfortable, and for most real uses you are likely to have enough with the fallback behavior.

Now, let me write down, what I think we decided we want 😆

So the behavior is as follows:

• -- is the chain operator, it means: as long as the previous command returns #t, go on with the next, exit otherwise.
• , is the fallback operator, it means: if the previous command returns #f, go on with the next, exit otherwise (fallback not executed)

I think this allows to express most chains one would need and the user can always rely on a combination of BLUE chains + shell operators such as && and ; to cover the full range of possibilities, but since we think this is quite an unlikely case, we provide a comfortable interface just for BLUE chains with fallbacks.

With that in mind, I've corrected a bug that I noticed with your examples, now the expected output should be:

# Expect (true), fallback not executed.
$ blue true , false -- false
;;; (true)
# Expect (false true true)
$ blue false -- false , true -- true
;;; (false)
;;; (true)
;;; (true)
# Expect (false false true)
$ blue false -- false , false -- false , true , false 
;;; (false)
;;; (false)
;;; (true)

What do you think? Now it seems to be what we want.

@old wrote in https://codeberg.org/lapislazuli/blue/pulls/302#issuecomment-18808406: > blue false -- false , true -- true I think we are looking at different goals here. It seems we didn't wrote it down, but, if I recall correctly, we decided not to support a complete tree as it would make the CLI usage a bit uncomfortable, and for most real uses you are likely to have enough with the fallback behavior. Now, let me write down, what I think we decided we want 😆 So the behavior is as follows: - `--` is the chain operator, it means: as long as the previous command returns #t, go on with the next, exit otherwise. - `,` is the fallback operator, it means: if the previous command returns #f, go on with the next, exit otherwise (fallback not executed) I think this allows to express most chains one would need and the user can always rely on a combination of BLUE chains + shell operators such as `&&` and `;` to cover the full range of possibilities, but since we think this is quite an unlikely case, we provide a comfortable interface just for BLUE chains with fallbacks. With that in mind, I've corrected a bug that I noticed with your examples, now the expected output should be: ``` # Expect (true), fallback not executed. $ blue true , false -- false ;;; (true) # Expect (false true true) $ blue false -- false , true -- true ;;; (false) ;;; (true) ;;; (true) # Expect (false false true) $ blue false -- false , false -- false , true , false ;;; (false) ;;; (false) ;;; (true) ``` What do you think? Now it seems to be what we want.

old commented 2026年07月09日 14:07:20 +02:00

What do you think? Now it seems to be what we want.

Yes. But the examples in the commit message are wrong. We can't express S-EXP then.

> What do you think? Now it seems to be what we want. Yes. But the examples in the commit message are wrong. We can't express S-EXP then.

pastor commented 2026年07月09日 14:18:35 +02:00

@old well, I just meant that that would be the sexp equivalent, not that you can do all the things you can in the SEXP, if you find it confusing we can drop those

@old well, I just meant that that would be the sexp equivalent, not that you can do all the things you can in the SEXP, if you find it confusing we can drop those

pastor commented 2026年07月09日 14:39:01 +02:00

@old I've added a clarification note on the commit message.

@old I've added a clarification note on the commit message.

pastor commented 2026年07月09日 16:10:23 +02:00

@old Now it's ready, I've added a regression test for the new fallback behavior.

@old Now it's ready, I've added a regression test for the new fallback behavior.