Qi Compiler Sync Aug 19 2022

Bindingspec Meta-DSL Intro

Qi Compiler Sync Aug 19 2022

Adjacent meetings: Previous | Up | Next

Summary

We spent our time on:

• A short introduction to the "binding spec" meta-DSL
• Separating core forms from non-core forms in the Qi source
• Starting to add core forms, one at a time, into a bindingspec grammar specification
• Reviewing handling of different cases of macro rules at a high level (e.g. identifiers, forms with multiple arguments, non-core forms, catch-all error handling cases, pass-throughs, escapes)

"Binding Spec" Meta-DSL

This meta-DSL generates an expander for a language given a grammar of the core language, and provides some utilities for compilation of the core language as well.

We installed this from bindingspec, and also its dependency ee-lib.

Detecting Invalid Syntax

As bindingspec has access to the core language grammar, it can provide error messages that show the expected forms of the syntax.

Question: How should we handle the case where Qi syntax matches a Racket function name?

Possible options

1. Be strict about it and assume that they meant the Qi form
2. Be lax about it and require explicit declaration to the effect that certain forms should be handled strictly, or that certain syntactic variations of the form should result in error messages
3. Be strict, but allow explicit declaration of pass-throughs, that is, syntax that may match a different rule and cannot be inferred to be invalid

We agreed that being strict about it, i.e. (1), is simplest for now, and we can review it if we run into any edge cases. If the user means to use a Racket function that has the same name as a Qi form, they would need to use esc. One consequence though is that it may not then be possible to partially apply such a function using Qi. For example, (~> (group 5) ...) for some Racket function named group would not work (it would raise a syntax error that this does not match expected (Qi) group syntax), and even esc would not help here. This is a case that should be reviewed when the time comes (possibilities: introduce a new partial form for this, or extend support in bindingspec for passthroughs, i.e. (3). E.g. a passthough involving an explicit template, like _ or __, could be easy to detect and pass through).

Good Error Messages

Syntax-parse has a ~describe form that can provide useful error messages in terms of expected patterns, but it appears to be inconsistent between a case like group vs (group), where the former provides a helpful message enumerating the expected patterns, while the latter simply says "error while matching many patterns". To remedy this, we could either request an upstream fix from syntax-parse (we should probably do this at any rate, in case this would be considered a bug), or we could handle it at the bindingspec level. We could probably start with the latter.

Next Steps

• Organize forms into core vs non-core in the in-progress compiler PR
• Rewrite all non-core forms as Qi macros (i.e. not internal to the code generation macro as the core forms should be)
• Start a branch with the in-progress bindingspec changes as a PR against the current main compiler branch (small-core-language) that can be merged when it is minimally functional
• Upgrade Racket to 8.6 to get the all-defined-out bugfix related to binding spaces that we encountered a while ago which was fixed in 8.4. Note: raco pkg migrate is a useful tool that should make upgrades in general painless and not worth putting off.
• Bindingspec: "Strict" error messages and related changes
• Make Discourse and Discord "events" for these meetings in the future, as that will translate into local timezones and make it easier for people to join.

Participants

Michael, Sid, Stephen