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

deep-matching on syntax objects #81

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

gelisam
Copy link
Owner

@gelisam gelisam commented May 24, 2020

pmatch is very convenient for deep-matching on datatypes, here is a version for syntax objects. That should make writing macros more pleasant!

gelisam added 3 commits May 23, 2020 12:28
previously the only allowed shape was (macro-name arg1 arg2 arg2), now
(macro-name (arg1 arg2) arg3), (macro-name arg1 (arg2 (arg3 arg4))) etc.
are also supported.
(example (m1 foo bar baz)) -- '(m1 foo bar baz)
(example (m2 foo)) -- 'foo


Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The following implementation is way more complicated than it needs to be. I wrote it first, and then I wrote syntax-pmatch. I then tried to rewrite define-syntax-rule in terms of syntax-pmatch, but I encountered #80 . So I'll leave it as-is for now.

@gelisam
Copy link
Owner Author

gelisam commented May 24, 2020

One feature I would like to implement next is the foo ... pattern to match on a list of items. But in order to make that useful, we'd need a corrsponding ,(foo ...) pattern in quasiquote, and I've never quite managed to understand how that function works.

@gelisam
Copy link
Owner Author

gelisam commented May 24, 2020

hmm, did I do something dumb performance-wise? A few tests are running much slower now:

define-syntax-rule: was 1.13s, now 7.87s
which-problem: was 2.15s, now 17.42s
double-define: was 1.48s, now 10.63s

@david-christiansen
Copy link
Collaborator

Did you ever get some insight into the slowdowns? I suspect that it's a combination of the deep matching taking time to be expanded into large code, combined with said large code running slowly, but it would be interesting to know how much of it is our expander and how much is our interpreter.

Base automatically changed from master to main January 12, 2021 23:13
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.

2 participants