-
Notifications
You must be signed in to change notification settings - Fork 24
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
Machine: Handle evidence #164
Conversation
For some reason, |
Also, while I wanted to use |
Maybe stack size? |
If we absolutely have to add |
Ah, yes, that's a better name. |
f85fb62 uses Note: the current implementation would break if the type of |
e034edf
to
6c5f60d
Compare
@phischu tested it on his machine and it was indeed the stack limit being reached. |
8befd6b
to
2eab1d4
Compare
I have now semi-splitted out evidence. It is still synonymous int in most places (i.e. |
Why does |
I think both are reasonable. I understand I am not strongly opposed to changing it to |
2eab1d4
to
f7370f9
Compare
After rethinking it, I changed |
(and rebased to current |
Also removes now unused `ComposeEvidence` instruction
Note: `params.map(transform)` should take care of evidence parameters, too
If the evidence is 0, we still want to `shift0 1` etc.
* `LiteralEvidence` and `ComposeEvidence` to work with evidence * Scala type alias `Evidence` and Machine type alias `builtins.Evidence` * Alias `builtins.Here` and `builtins.There(_)` for literal evidence * `PopStacks` now pops n+1 stacks (until the nth one)!
e123607
to
67bd2ad
Compare
Handle evidence and use it to execute effect operations in the correct context.
Is not yet correctly implemented in the llvm backend (number of stacks to pop is ignored),
so widely untested.