https://pantsbuild.org/ logo
Join Slack
Powered by
oh wow. i just thought of a pretty wild syntax for...
# development
w
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
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
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
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
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
If we like this syntax, will we be ad-
dict
-ed to it?
🥁 1
☢️ 1
🍅 1
b
Should 
input1
be a string?
w
No: it is the actual value of that type
b
😵 Got a real-world example? I'm not grokking
ohhhhhh it's 
{instance: type}
?
w
yea
b
They have to be static though, for parsing's sake?
w
Only the types do
But yes: the "shape" and types of the dict* are static
b
😬 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
i don’t think that we can/should get rid of the 1 arg syntaxes (yet)
👍 1
but we’ll see…?
h
yeah I take back my proposal to get rid of the 1 arg syntaxes (for now)
b
parsing still seems like a stumbling block. It's gonna be hard not to want to use variables 😅
w
@bitter-ability-32190: not sure what you mean there… this is equivalent to the existing syntax in that regard
b
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
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
from a parsing perspective, that sounds like “quickly fail with a useful explanation if you encounter anything other than a dict literal”
b
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
yea, true
b
I also wonder how we can make the "multiple inputs" really noticeable at the declaration site of a rule
w
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
You lost me 😛
w
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
Open in Slack
PreviousNext
Powered by