-
Notifications
You must be signed in to change notification settings - Fork 119
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
strictness of indexing #422
Comments
This issue afflicts other primitives that take a strict number, in cases where the type of the result is a singleton. For example
or
where the REPL gets in an infinite loop. So the REPL does not appear to have the domains advertised in the Reference implementation, in particular we have extra error and bottom elements. |
Indeed, these are pretty tricky issues. We could solve them by doing the necessary eta-expansion at every indexing call, but I suspect that would result in an enormous performance degradation in the common cases. I have some vague ideas in mind for how we could deal with these issues better. The most fully formed is this: in the evaluator, always be evaluating in the context of a "demand shape", which identifies both the desired result type, and how much of the resulting shape the use site promises to examine. This would essentially perform a runtime analogue of demand analysis. Then, using that information, we would have enough context to know when we need to perform expensive eta-expansions, and when we can just go ahead and force things. In many cases, I hypothesize, we would get the more efficient eager evaluation behavior, while still correctly handling the tricky corner cases. |
The reference interpreter was updated in #866, which removes some, but not all, of these mismatches. |
Fixed via #1136 |
Here's another place where the reference evaluator and REPL evaluator disagree:
I think the reference evaluator actually is strict in the index, but the domain for () has no room for an error, as we see in
We of course see the same issue with the other three indexing operators
!
,@@
, and!!
.The text was updated successfully, but these errors were encountered: