Default value of state variable #71

old commented 2025年08月22日 16:25:09 +02:00

Given for example a build command that do this:

(define-command (build-command arguments)
 ((invoke "build"))
 (parameterize ((current-c-toolchain #%?CC))
 (require ...)))

This command will parameterize the current C toolchain for compiling <c-binary> with the value of the variable CC. However, that variable could be not defined in the blueprint configuration at all. But it can also be defined dynamically by the user by doing ./configure CC=gcc. Thus, it is entirely possible for a variable to maybe defined.

Currently, trying to lookup a state variable that is not defined will raise an exception. And so the current way of handling this is to do:

(define-command (build-command arguments)
 ((invoke "build"))
 (parameterize ((current-c-toolchain (or (false-if-exception #%?CC) "gcc")))
 (require ...)))

I think it could be interesting to have a way to specify a default value instead of raising an exception. For example, we could do #%?CC|"gcc"|. So now, either the variable CC is defined and its value is returned, or the string "gcc" is returned.

Thus one could do:

(define-command (build-command arguments)
 ((invoke "build"))
 (parameterize ((current-c-toolchain #%?CC|"gcc"|))
 (require ...)))

Thoughts?

Given for example a build command that do this: ```scheme (define-command (build-command arguments) ((invoke "build")) (parameterize ((current-c-toolchain #%?CC)) (require ...))) ``` This command will parameterize the current C toolchain for compiling `<c-binary>` with the value of the variable `CC`. However, that variable could be not defined in the blueprint configuration at all. But it can also be defined dynamically by the user by doing `./configure CC=gcc`. Thus, it is entirely possible for a variable to **maybe** defined. Currently, trying to lookup a state variable that is not defined will raise an exception. And so the current way of handling this is to do: ```scheme (define-command (build-command arguments) ((invoke "build")) (parameterize ((current-c-toolchain (or (false-if-exception #%?CC) "gcc"))) (require ...))) ``` I think it could be interesting to have a way to specify a default value instead of raising an exception. For example, we could do `#%?CC|"gcc"|`. So now, either the variable `CC` is defined and its value is returned, or the string `"gcc"` is returned. Thus one could do: ```scheme (define-command (build-command arguments) ((invoke "build")) (parameterize ((current-c-toolchain #%?CC|"gcc"|)) (require ...))) ``` Thoughts?

pastor commented 2025年08月24日 20:16:02 +02:00

I like the idea. The syntax does not look very lispy but I cannot think of anything better...

I like the idea. The syntax does not look very lispy but I cannot think of anything better...

old commented 2025年08月24日 23:03:23 +02:00

Well it could be this:

#%?CC("gcc")

So really the template is:

#%?VARIABLE(expression)

So one could do this:

#%?CC((or (getenv "CC") "gcc"))

Or this:

;; #%?VARIABLE|expression|
#%?CC|(or (getenv "CC") "gcc")|

Well it could be this: ```scheme #%?CC("gcc") ``` So really the template is: ```scheme #%?VARIABLE(expression) ``` So one could do this: ```scheme #%?CC((or (getenv "CC") "gcc")) ``` Or this: ```scheme ;; #%?VARIABLE|expression| #%?CC|(or (getenv "CC") "gcc")| ```

pastor commented 2025年08月27日 22:06:50 +02:00

I think I find this one less confusing:

;; #%?VARIABLE|expression|
#%?CC|(or (getenv "CC") "gcc")|

The other one looks like you are evaluating a function.

I think I find this one less confusing: ``` ;; #%?VARIABLE|expression| #%?CC|(or (getenv "CC") "gcc")| ``` The other one looks like you are evaluating a function.

old commented 2025年08月28日 00:55:42 +02:00

Note that this prevent the usage of | in variable name then.

Note that this prevent the usage of `|` in variable name then.

pastor commented 2025年08月28日 18:39:15 +02:00

Oh, well. That's a good reason not to do that, I guess. We can go with the (...) syntax.

Oh, well. That's a good reason not to do that, I guess. We can go with the `(...)` syntax.

old commented 2025年09月10日 00:30:01 +02:00

I'm moving this to backlog since I don't quite like the syntax and will wait until the issue arise more.

I'm moving this to backlog since I don't quite like the syntax and will wait until the issue arise more.

old commented 2025年12月12日 22:59:25 +01:00

Remove. Just use computation-ask/cps

Remove. Just use `computation-ask/cps`

pastor commented 2025年12月16日 12:43:17 +01:00

@old wrote in #71 (comment):

Remove. Just use computation-ask/cps

That's fine, although as a user that name is not telling me much. Please, could you give the rationale for the /cps suffix?

@old wrote in https://codeberg.org/lapislazuli/blue/issues/71#issuecomment-8886648: > Remove. Just use `computation-ask/cps` That's fine, although as a user that name is not telling me much. Please, could you give the rationale for the `/cps` suffix?

old commented 2025年12月16日 17:18:20 +01:00

Continuation passing style. You pass the success and failure continuations as parameter so you don't have to check the returned value.

(computation-ask/cps 'FOO (lambda (value) (pk 'success value)) (lambda () (pk 'error)))

Continuation passing style. You pass the success and failure continuations as parameter so you don't have to check the returned value. ```scheme (computation-ask/cps 'FOO (lambda (value) (pk 'success value)) (lambda () (pk 'error))) ```

pastor commented 2025年12月16日 21:24:17 +01:00

Got it, we will have to be clear about this usage in the manual.

Got it, we will have to be clear about this usage in the manual.