Skip to content
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

WIP on Mutations Dec 2023 #261

Open
1 of 7 tasks
lhstrh opened this issue Dec 12, 2023 · 1 comment
Open
1 of 7 tasks

WIP on Mutations Dec 2023 #261

lhstrh opened this issue Dec 12, 2023 · 1 comment

Comments

@lhstrh
Copy link
Member

lhstrh commented Dec 12, 2023

  • revisit key chain logic
  • static vs. dynamic scope
  • set as method in sandbox, not the port itself
  • set port for reactions (check that port is among effects)
  • set port for mutations (add dependency if not present)
  • unit tests for Sieve-like mutations discussed on whiteboard
  • split reactor.ts into smaller files
@axmmisaka
Copy link
Collaborator

This has been paused forever, but just writing a memo for me here:
In one meeting Prof. Lee and others found that it might be a better idea to eliminate the ability for mutations to write to ports, i.e. the only effect a mutation can have is to carry out the 4 API calls outlined in the tech report.
This will not impact the ability of mutation to achieve its tasks because one can split an old mutation into a reaction and a mutation, one of which does the connection, and the other does the writing or nop.
In the code generator the syntax should therefore replicate what we have for reactions
mutation [<name>] (triggers) [<uses>] [-> <effects>] [{= ... body ...=}]
And unlike in reactions effects must be ports.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants