https://pantsbuild.org/ logo
w

witty-crayon-22786

08/24/2022, 5:05 PM
oh wow. i just thought of a pretty wild syntax for https://github.com/pantsbuild/pants/issues/7490…:
Copy code
output = await Get(Output, {input1: Input1, input2: Input2})
❤️ 1
💯 2
works (afaict?) because
Get
inputs must always be hash/eq-able.
and declares the type of the input as a dict value… which ends up looking like a type ascription
and leaves room for more syntax by expanding the dict value (to indicate that something is optional, etc)
h

hundreds-father-404

08/24/2022, 5:09 PM
I like it. Do you think something like this for 0 and 1 arg?
Copy code
await Get(Output, {input1: Input})
await Get(Output, {})
I think it's strongly worth considering converging around a single syntax for
Get
. The rule API is already hard to learn: having several different ways of using a core abstraction adds to the confusion
w

witty-crayon-22786

08/24/2022, 5:10 PM
maybe eventually.
the downside of this syntax is the performance implication of creating a dict. my expectation is that callsites which use multiple parameters will be fairly rare though.
👍 1
h

hundreds-father-404

08/24/2022, 5:15 PM
so then zero *param would be
await Get(Output)
, which I like Would 1-param stay the same as before, with the 2 vs 3 arg variants?
w

witty-crayon-22786

08/24/2022, 5:16 PM
yea, i think that nothing changes (for now) for the 1 arg case, and 0 arg looks like
Get(Output)
.
👍 1
and who knows: if multi-argument callsites end up being way more common, then the dict may not work. we’ll see.
f

fast-nail-55400

08/24/2022, 5:44 PM
If we like this syntax, will we be ad-
dict
-ed to it?
🥁 1
☢️ 1
🍅 1
b

bitter-ability-32190

08/24/2022, 8:25 PM
Should
input1
be a string?
w

witty-crayon-22786

08/24/2022, 8:25 PM
No: it is the actual value of that type
b

bitter-ability-32190

08/24/2022, 8:26 PM
😵 Got a real-world example? I'm not grokking
ohhhhhh it's
{instance: type}
?
w

witty-crayon-22786

08/24/2022, 8:26 PM
yea
b

bitter-ability-32190

08/24/2022, 8:27 PM
They have to be static though, for parsing's sake?
w

witty-crayon-22786

08/24/2022, 8:27 PM
Only the types do
But yes: the "shape" and types of the dict* are static
b

bitter-ability-32190

08/24/2022, 8:28 PM
😬 I like the idea. I'm a bit weary of the parsing, and of the 1-arg shorthand having to duplicate (e.g. going from
Get(X, Y(..))
to
Get(X, {Y(...): Y})
w

witty-crayon-22786

08/24/2022, 8:29 PM
i don’t think that we can/should get rid of the 1 arg syntaxes (yet)
👍 1
but we’ll see…?
h

hundreds-father-404

08/24/2022, 8:32 PM
yeah I take back my proposal to get rid of the 1 arg syntaxes (for now)
b

bitter-ability-32190

08/24/2022, 8:32 PM
parsing still seems like a stumbling block. It's gonna be hard not to want to use variables 😅
w

witty-crayon-22786

08/24/2022, 8:32 PM
@bitter-ability-32190: not sure what you mean there… this is equivalent to the existing syntax in that regard
b

bitter-ability-32190

08/24/2022, 8:33 PM
Maybe to us. As a newcomer it's even less obvious that we can't dynamically build inputs this way.
At least before, there wasn't a mutable built-in object's worth of wiggle room for getting creative 🙂
h

hundreds-father-404

08/24/2022, 8:34 PM
you can: the only thing that has to be explicitly set is the
: Input1
type, which is the type ID. the key can be a variable
w

witty-crayon-22786

08/24/2022, 8:34 PM
from a parsing perspective, that sounds like “quickly fail with a useful explanation if you encounter anything other than a dict literal”
b

bitter-ability-32190

08/24/2022, 8:37 PM
a dict literal whose key/value pairs are static (e.g. no
**
) and whose values are types. All that said, I love the creativity and the idea. I'll wait for the PR to see how creative we have to get 🙂
w

witty-crayon-22786

08/24/2022, 8:38 PM
yea, true
b

bitter-ability-32190

08/24/2022, 8:47 PM
I also wonder how we can make the "multiple inputs" really noticeable at the declaration site of a rule
w

witty-crayon-22786

08/24/2022, 9:11 PM
most of the time they won’t be: a `Platform`/`Environment` will likely be consumed by most/all processes that a
@rule
invokes (transitively), and in the computation of environment variables and options that it consumes (again, transitively), but not in its signature
(for example)
b

bitter-ability-32190

08/24/2022, 9:12 PM
You lost me 😛
w

witty-crayon-22786

08/24/2022, 9:13 PM
the reason that a
Get
is type driven is that it does not represent positional arguments to a particular rule: rather, the transitive inputs necessary to compute an output type
`Param`s are eventually used as positional args to `Rule`s, but it’s important to note that the `Param`s in a
Rule
instance’s identity/memoization-key will not always become the positional arguments to that `Rule`: in many cases, a
Param
will be used by a `Rule`’s transitive dependencies in order to produce an output value that becomes either a positional argument to the
Rule
as it starts, or the result of a
Get
while a coroutine
Rule
runs.
the eventual need to differentiate entire subgraphs by the Platform is part of why the
@rule
API is shaped the way it’s shaped