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

Conditionals #747

Open
dfellis opened this issue Jun 10, 2024 · 1 comment
Open

Conditionals #747

dfellis opened this issue Jun 10, 2024 · 1 comment
Milestone

Comments

@dfellis
Copy link
Member

dfellis commented Jun 10, 2024

The Alan v0.2 conditionals concept is that if <conditional> { ... } else ... is rewritten into cond function calls where all function bodies are branchless and must run until the end.

This means return statements are only valid as the last statement in a function body at that point.

This also means that conditional branches that don't return and pass back control flow to the higher layer must instead bolt on the follow-up code to the tail of their own function body. Excepting only if all branches of a conditional do not return, where fall-through is allowed, and all branches where the conditional does return, in which case follow-on code is a failure.

The cond function will be just like any other function, so users can write their own that accepts something other than bools. This will be used for native GPGPU support, as both branches of a conditional need to be transformed into an AST to serialize to wgsl for the GPU.

@dfellis dfellis added this to the v0.2 release milestone Jun 10, 2024
@dfellis
Copy link
Member Author

dfellis commented Jul 29, 2024

cond for bool has been implemented. If both branches are defined they need to both return the same type, if one branch is defined it auto-wraps into a Maybe{T} for the true branch.

This does make it a good fit for use in assignment statements, and I wonder what, if any, syntactic sugar should exist for that usage.

It wouldn't be too hard to get a ternary-like set of operators, though there would be the unexpected closure function syntax necessary. It would also be possible to add some syntactic sugar, which could work like Rust or Python or do something different entirely.

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