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

Sketch of statically-typed Exprs #5235

Draft
wants to merge 9 commits into
base: main
Choose a base branch
from
Draft

Sketch of statically-typed Exprs #5235

wants to merge 9 commits into from

Conversation

steven-johnson
Copy link
Contributor

This is a a rough sketch of an idea I have been pondering: could we usefully add more (optional) static typing to the Halide C++ IR?

This PR just adds a wrapper around Expr to allow for static typing (a la Buffer<>). The idea here is that an ExprT<type> is an Expr that can only a value of the given type (or be undefined).

The main goal here is to allow for easier readability in complex pipelines (eg if an Expr is expected to be of type uint8, this makes it more plain when reading the source code, and failures would happen at compile time, not runtime).

I'm not entirely sure if I like this or not, so I didn't expend a lot of energy trying to complete it -- there may be holes in the implementation.

In the name of science, I modified cast<T>() to return ExprT<T>, and Var to be convertible to ExprT<int> (rather than plain Expr).

If this seems remotely desirable, perhaps it could lead to similar wrappers for Func, ImageParam, etc.

Thoughts welcome.

This is a a rough sketch of an idea I have been pondering: could we usefully add more (optional) static typing to the Halide C++ IR?

This PR just adds a wrapper around `Expr` to allow for static typing (a la `Buffer<>`). The idea here is that an `ExprT<type>` is an Expr that can only a value of the given type (or be undefined).

The main goal here is to allow for easier readability in complex pipelines (eg if an Expr is expected to be of type uint8, this makes it more plain when reading the source code, and failures would happen at compile time, not runtime).

I'm not entirely sure if I like this or not, so I didn't expend a lot of energy trying to complete it -- there may be holes in the implementation.

In the name of science, I modified `cast<T>()` to return `ExprT<T>`, and `Var` to be convertible to `ExprT<int>` (rather than plain `Expr`).

If this seems remotely desirable, perhaps it could lead to similar wrappers for Func, ImageParam, etc.

Thoughts welcome.
@steven-johnson
Copy link
Contributor Author

I'm not going to mark this as 'ready for review', since it's really just a design experiment at this point, but would like to get opinions from people about the general concept.

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

Successfully merging this pull request may close these issues.

1 participant