-
Notifications
You must be signed in to change notification settings - Fork 45
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
Specify evaluation order regarding functions #292
Comments
If we over-specify here, we could end up eliminating some big possible optimizations. For example, an implementation might want to pre-evaluate constant expressions (such as One use case for this would be a |
Oh, yes, everything I said before only applies to impure functions. An implementation is free to reorder or drop calls to pure ones as long as the result stays the same, and nobody is going to notice these changes, because functions are pure. This opens broad possibilities for constant folding and common subexpression elimination. But that requires knowledge which functions are pure and which are not. |
Functions are written in the host language and can both observe and mutate the global state (as well as the bundle they are called from), so order of evaluation should be defined for better portability.
Implementations should be allowed to skip evaluating functions when they hit their internal limits (neccessary for #277).
The text was updated successfully, but these errors were encountered: