Proposal for `@goal @list`

[xonixx]

Motivation: simplify logic in https://github.com/xonixx/intellij-awk/blob/f4e36b0121a82a4840794b96a476e089b194e7b1/Makesurefile#L65 and below.

---

@goal name @list val1 'val2' $'val3'
@depends_on other@$ITEM
echo $ITEM $INDEX $TOTAL


@list L val1 'val2' $'val3'
@goal name @list L

@glob G '*.txt'
@goal name @glob G

---

@goal name @list L # simple
@goal name @list @L
@goal name @list @ref L

---

@depends_on "other@$ITEM"
@depends_on other@ITEM
@depends_on other@
@depends_on @item other # ?

---

• List multiline?
• Should we extend \ to all directives? Cons: adds more ways to do the thing

@list L \
    val1 \
    val2 \
    Val3

@depends_on \
  Goal1 \
  Goal2 \
  goal3

@goal \

What if just

@list L val1 val2
Val3
Val4 val5 #comment
# comment
Val6

---

Substitutes in list values? Exclude for now?

---

mix @depends_on & @depends_on @item

• What if we need different logic in template goal?
• Is this really relevant? Cases: different @depends_on. Different scripts can be handled with if/else
• This also applies to @glob — but it’s been OK so far…

Idea 1. Allow override? Why additional keyword? Because dup goals naturally cause error.

@override @goal name@val

• only delta? … Seems less clear to use.

Idea 2. Just exclude value from list and use custom goal!!!

---

• newlines in strings? Why: may be needed to @list values
• This needs to adjust global parsing

——— Another use-case could be to help with « goal parameters » scenario https://github.com/casey/just#recipe-parameters. In makesure we deliberately rejected the idea of parameterized goals https://github.com/xonixx/makesure#omitted-features. However the presence of @list can help to cover all possible parameters in a build file like so:

@goal g @list param1 param2 param3
  program —with-param "$ITEM"

# ./makesure g@param2

Cons: however it’s not clear why the above is better than explicit

@goal g@param1 # actually you can set more meaningful name!
@doc and have doc string
  program —with-param param1

@goal g_param_2
  program —with-param param2

…
# also can abstract 'program —with-param paramName' in @lib

Cons2: Looks like the semantics of ./makesure g # invoke-all is not always meaningful for this use case.

Thought: Maybe we need even more flexible idea of @goal g @array key=val key2=val2. The idea here would be to have decoupled goal names g@key from implementation over val.

To me this parameterized goals use-case plays more against this feature than in favor of it, since the feature adds more ways to do the same thing not necessarily in better way.