Fix weird syntax pair bug #141
Conversation
`syntax-e` when given a syntax list seems to produce a syntax pair in some cases. This was causing the `cdr` of the syntax _pair_ to unexpectedly produce a syntax object which would then have the transforming function inappropriately applied to it. We don't know why syntax-e does this, but the fix for now is to first attempt to use `syntax->list` which does more reliably produce a list, and if that fails (e.g. identifiers), then use `syntax-e` as before.
countvajhula
had a problem deploying
to
test-env
GitHub Actions
Failure
|
Does using |
This uses a new syntax property from Syntax Spec that identifies which syntax subexpressions are core language forms, and these are the only ones we will attempt to rewrite. We can't rely on either syntax-e or syntax->list on its own since they aren't a robust source of this information. For instance, [condition consequent] clauses of `partition` would be picked up as lists, but it wouldn't be appropriate to attempt to rewrite them.
|
@benknoble that's a great idea, will keep that in mind for next time! We ended up going with a more robust fix than the Most of the compiler tests now fail since the actual logic depends on the presence of this new syntax property (from Syntax Spec) which the tests don't yet know about. I attempted to add that in the tests earlier today and most of them were passing but a few weren't, and I haven't had a chance to debug those failures yet. So, I just committed the fix we wrote during the meeting for now. |
The tree traversal function `find-and-map/qi` now only attempts to apply the transforming function if the `nonterminal` syntax property is present on the syntax node, which indicates that it is a legitimate use of a core Qi form, and thus one that it would be appropriate to rewrite. The compiler tests are unaware of this new property so they all fail. This modifies the syntax in the tests by first traversing it and attaching the `nonterminal` property to every node, so that it should be effectively the same as before the recent changes. But at the moment, a couple of these tests are still failing.
|
I figured I'd just commit my first attempt at fixing the tests too, for what it's worth. I haven't had a chance to investigate why these two tests are failing: |
The toplevel syntax object in a syntax list was not getting the new `nonterminal` syntax property.
|
@benknoble |
countvajhula
had a problem deploying
to
test-env
GitHub Actions
Failure
countvajhula
had a problem deploying
to
test-env
GitHub Actions
Failure
|
This fix looks like it's working. However, there's another issue now where the |
countvajhula
merged commit 9f30fdc
into
drym-org:lets-write-a-qi-compiler
| [(syntax-list? tree) (f (datum->syntax tree | ||
| (tree-map f (syntax->list tree))))] |
There was a problem hiding this comment.
I suspect we should be passing the other two optional arguments to datum->syntax here, but since it's only for tests it might not be relevant?
There was a problem hiding this comment.
Interesting, I didn't realize that properties could be automatically propagated by passing the input syntax for the prop argument. That is very useful to know. I'll make this change in a follow-up PR, thank you.
Summary of Changes
This fixes the weird syntax pair bug,
but we don't really understand why it happens this way.The reason it was happening is that
syntax-eis apparently not guaranteed to produce a list even if the input happens to be a syntax list. Since Qi has some core syntax that can be used in identifier form, that meant that expansion was producing a syntax pair here rather than a syntax list (for reasons that should be considered internal implementation details that we should not rely on due to syntax-e making no promises regarding producing a syntax list).So instead of doing a naive tree traversal where we attempt to optimize every syntax component, we had a couple of more robust options to consider:
We went with a third, short-term option, for Syntax Spec to attach a syntax property indicating that syntax is or isn't a full and well-formed use of core language syntax. And then in our naive traversal, we look for this property and only attempt to optimize if it's present.
(this is WIP from today's meeting)
Public Domain Dedication
(Why: The freely released, copyright-free work in this repository represents an investment in a better way of doing things called attribution-based economics. Attribution-based economics is based on the simple idea that we gain more by giving more, not by holding on to things that, truly, we could only create because we, in our turn, received from others. As it turns out, an economic system based on attribution -- where those who give more are more empowered -- is significantly more efficient than capitalism while also being stable and fair (unlike capitalism, on both counts), giving it transformative power to elevate the human condition and address the problems that face us today along with a host of others that have been intractable since the beginning. You can help make this a reality by releasing your work in the same way -- freely into the public domain in the simple hope of providing value. Learn more about attribution-based economics at drym.org, tell your friends, do your part.)