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

[enhancement] DSLX should support "where" clauses to get parametric derived expression out of parametric position #1404

Open
cdleary opened this issue May 12, 2024 · 0 comments
Labels
dslx DSLX (domain specific language) implementation / front-end enhancement New feature or request long-term-enhancement Issues that are sensible enhancements but XLS devs expect may not be addressed in the near-term

Comments

@cdleary
Copy link
Collaborator

cdleary commented May 12, 2024

What's hard to do? (limit 100 words)

This is more of a syntactic nicety so marking as long-term-enhancement, but wanted to file so I had an issue to point people at. For a signature like:

fn replicate<N: u32, M: u32, O: u32 = {N*M}>(x: bits[M]) -> bits[O] {

Ideally we'd be able to specify the output bit count outside the parameter list when it's really just inferred from the input side parameters; something like:

fn replicate<N: u32, M: u32>(x: bits[M]) -> bits[O]
  where O: u32 = {N * M} {

Current best alternative workaround (limit 100 words)

Just putting the "derived" parametric expression in the normal parametric list, as shown in the first snippet.

Your view of the "best case XLS enhancement" (limit 100 words)

The where clauses could help us make the function signatures a little more readable by getting the derived things more out of the way. It would be nice if we implemented them, Rust has a similar facility for getting type trait bounds out of the main signature; i.e. https://doc.rust-lang.org/rust-by-example/generics/where.html

@cdleary cdleary added enhancement New feature or request dslx DSLX (domain specific language) implementation / front-end long-term-enhancement Issues that are sensible enhancements but XLS devs expect may not be addressed in the near-term labels May 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dslx DSLX (domain specific language) implementation / front-end enhancement New feature or request long-term-enhancement Issues that are sensible enhancements but XLS devs expect may not be addressed in the near-term
Projects
None yet
Development

No branches or pull requests

1 participant