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

Assert that all INT(boz, kind) forms are evaluated properly #270

Open
raehik opened this issue May 16, 2023 · 1 comment
Open

Assert that all INT(boz, kind) forms are evaluated properly #270

raehik opened this issue May 16, 2023 · 1 comment

Comments

@raehik
Copy link
Collaborator

raehik commented May 16, 2023

I'm unsure how the current evaluator performs here. We should write some granular tests.

Currently when we come across a function call, we evaluate all the arguments and pass them along to another evaluator according to the function/intrinsic name. That means boz would get evaluated without context, which defaults to INTEGER(4). Then the INT intrinsic is evaluated, meaning the INTEGER(4) is coerced to an INTEGER(2). Is this different to coercing directly to an INTEGER(2) in the first place?

This would be resolved easily by adding a BOZ constructor to the scalar values. I've shied away from that because it feels weird.

@raehik
Copy link
Collaborator Author

raehik commented May 16, 2023

Adding to the above: The problem with adding an explicit BOZ constructor to the scalar values is that they would no longer be safely representable in memory. BOZs are a purely compile-time construct.

I think certain intrinsics need special handling where they unwrap and inspect the next layer. So for INT, instead of evaluating all arguments immediately, we pass them as their syntactic constructs. We handle ExpVal [...] ValBoz{} via a special case, like what is currently done in fortran-vars. Then the general case would evaluate arguments. (This would be a purely internal change -- I just did the easy thing where I get rid of AST types ASAP.)

I think one has to view INT(boz, kind) as a bottom-level expression that can't be broken down any further. Because boz by itself doesn't mean much (it requires context to interpret).

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

1 participant