-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add future types to DML #283
Comments
This issue was referenced by the following commit before migration:
|
I think I'm going to delay dealing with Migrated from internal repository. Originally created by @EvanKirshenbaum on Jul 05, 2023 at 10:41 AM PDT. |
The most straightforward way to support Migrated from internal repository. Originally created by @EvanKirshenbaum on Jul 05, 2023 at 11:00 AM PDT. |
Okay, that wasn't too bad. DML now supports
The latter form creates the variable immediately, and then performs the injection, which will wait for it to get the value. Note that because the declaration doesn't end until the injection does, this should only be done in a parallel block (at least until When a You can also reset the value to unbound. There's currently no way to do this from DML, but if I can figure out how to do it, I may want to have this happen when a The current implementation complains "not yet implemented" on
Migrated from internal repository. Originally created by @EvanKirshenbaum on Jul 06, 2023 at 2:12 PM PDT. |
When looking at how to support paths in a way that users can wrap their heads around (#282), one of the hardest questions was "How does the user split a single drop in two and do something with each resulting drop?"
The answer I've come up with is to take advantage of
Delayed[T]
and add a new meta-type,future T
to DML. This would be something that can hold aT
(and which has avalue
attribute that can be queried, i.e.,has a value
), but which actually holds aPostable[T]
and which converts to aT
by waiting to get a value. This would allow something likeThe two paths work in parallel, but
walk_after_split
doesn't happen until the split is done.If I'm going to do this, it should generalize to any type, because doing so gives me the ability to have out parameters. The basic notions are
future T
converts to aT
, waiting until it gets a value.T n
.future
is contravariant: afuture T
is afuture U
if aU
is aT
.future int
, you can pass in afuture float
, because the macro will (may?) assign it anint
, which is okay.T
variable into a macro that wants afuture T
, the value asserted will be assigned to the variable.future
returns.future
parameter probably creates a new variable that's linked to its passed parameter.future
itself, the linkage should probably go in both directions, so either can be asserted.future
values can only be assigned once, and only withT
values. (Assigning afuture
value will wait.)Migrated from internal repository. Originally created by @EvanKirshenbaum on Jul 03, 2023 at 5:03 PM PDT.
The text was updated successfully, but these errors were encountered: