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

Knowing the number of registers for a regexp #53

Open
tfeb opened this issue Jan 11, 2023 · 0 comments
Open

Knowing the number of registers for a regexp #53

tfeb opened this issue Jan 11, 2023 · 0 comments

Comments

@tfeb
Copy link

tfeb commented Jan 11, 2023

It would be nice if there was a function which, given a regexp (or the source of one), would return a count of the number of registers in it (in other words the length of the arrays that scan will return on a match for this regexp. It's not quite clear to me that that's fixed for a specific regexp (things like "(x)|y" for instance) but I think it is in fact.

The reason this would be useful is that it would enable case-like macros which treat regexps as literals to move a check from run-time to macroexpansion-time and hence catch program errors ealier. As an example I have a macro called regexp-case where this:

(regexp-case v
  ("^fo(o)?" (:registers (a b))
   ...))

is an error (more register variables than registers) but that error must be checked at run time, when it could be checked at macroexpansion time. The run-time check is extremely cheap (a known constant against the length of a vector) but having it at macroexpansion time would mean errors got caught earlier.

For the non ACL case an easy solution would be to return the number of registers from create-scanner as an additional value as it knows it. But that's arguably an incompatible change as anything which actually checks the number of values would break, if there is anything that does that. On the other hand create-scanner can already return only one value in the case of a function.

I don't know how it could be fixed for ACL since I'm not familiar with it any more.

This is probably too rare a case to justify a change, but I thought I would suggest it.

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