feature: case and cond statements

[Alizter]

We add a (case ...) constructor to dune_lang for actions which when expanded will reduce down to the matching branch.

We also add a (cond ...) constructor for checking blang values which will reduce down to the first true branch condition.

• doc
• test
• changelog
• fixes Adding some conditionals in the language #924

[gridbugs]

If I were consuming this error message I'd prefer to be told that the default case appears somewhere other than the end of the case statement in this instance.

[Alizter]

This is trickier since we parse the list backwards to check the (reversed) first is a default case. In order to find the default case we would have to parse the rest of them. There is also no guarantee that there is even a default case.

[gridbugs]

Strings in dune can be unquoted. What happens if the version file contains _? Would the _ case be treated as the default case or matching the _ string?

What if we changed the syntax so the default case doesn't require a condition at all. E.g.

(case %{read-lines:version}
 (2 (echo "version is 2"))
 (echo "version is not 2"))

[Alizter]

If version contained _ it would be compared to any other branch with pattern _. You can give such a pattern by quoting the _. For instance, here is a test I have added:

  $ cat > dune << EOF
  > (rule
  >  (alias foo)
  >  (action
  >   (case %{read-lines:version}
  >    ("_" (echo "version is _"))
  >    (_ (echo "version is default")))))
  > EOF

  $ dune build @foo
  version is default

  $ cat > version << EOF
  > _
  > EOF

  $ dune build @foo
  version is _

You second point:

This makes parsing more complicated. In fact it can event be ambiguous. Imagine you had a file called progn. Then

(progn (echo foo))

could mean the default case or the string progn.

[gridbugs]

Is the _ string a special value in other places in dune? As a user I would find it confusing for there to be some values which are treated differently when they are quoted since strings without spaces don't usually need to be quoted in dune.

[Alizter]

It has a precedent as a catchall value in the env stanza.

[gridbugs]

I'm looking at using this feature to convert opam commands with filters into dune actions as part of package management. Opam lets entire commands be included or excluded based on a boolean predicate.

For example:

build: [
  ["dune" "subst"] {dev}
  ["dune" "build" "-p" name "-j" jobs]
  ["sh" "-ex" "packaging/FreeBSD/create_package.sh"] {os = "freebsd"}
  ["sh" "-ex" "packaging/debian/create_package.sh"] {os-family = "debian"}
]

This could be translated a dune action. Note I'm using the (progn) action with no arguments as a no-op.

(progn
 (cond
  (%{dev} (run dune subst))
  (_ (progn)))
 (run dune build -p %{pkg-self:name} -j %{jobs})
 (cond
  ((= %{os} freebsd) (run sh -ex packaging/FreeBSD/create_package.sh))
  (_ (progn)))
 (cond
  ((= %{os-family} debian) (run sh -ex packaging/debian/create_package.sh))
  (_ (progn))))

For improving the ergonomics of using this feature to support commands in lockfiles translated from opam I think it would be useful to allow users to omit the default case and have the conditional action act like a no-op if none of the conditions are met. Also I think it would be useful to add a no-op action to dune so we don't have to use the (progn) hack to simulate one.

[Alizter]

@gridbugs I think defaulting to the noop will be a poor choice aimilar to the (optional) field in stanzas. Silent failures are difficult to debug. I would rather a user message get raised when there is no matching branch and allow people to default to a noop if needed.

[Alizter]

@gridbugs I've added a test demonstrating what happens with _ as a case in case.t. I've also improved the wording of the error message you mentioned.

[Alizter]

@gridbugs Something else we can try is allowing for the omission of the default case when in a lockfile and forcing user written actions to have default cases. That way we can have the lockfile convenience without users shooting themselves in the foot.

[Alizter]

Closing this as I don't think there is any wish to continue with it. Happy to reopen if needed.