Ideas and Issues for syntax/parse in Rhombus

[tail-reversion]

My first observation is that the interfaces can be simplified a bit because deprecated options can be omitted, literals needn’t be declared in Rhombus syntax templates, and the #:track-literals option of syntax-parse can always be implicitly active.

Questions Raised by Shrubbery

The syntax/parse pattern grammar has its S-, H-, EH-, and A-patterns. What should the pattern grammar for the Rhombus version look like? This will depend partly on the particular underlying language grammar that is finally selected.

As a first step towards porting syntax/parse to Rhombus, I suggest adding an operator, % (or some other name) that serves as an escape to the various pattern forms of syntax/parse. As an example:

'(%describe(($expr1 $op $expr2), "binary operation application"))

Of course, some patterns could be simplified with syntax-level operators, such as pat1 <&> pat2 being used for %and(pat1, pat2). In particular, for the times where the #:role part of a variable annotation is omitted, a binary annotation syntax like $var $: syntax_class could be used.

Significant Changes

These are some changes that I think could improve the clarity and utility of syntax/parse:

• Syntax classes require declaration of exported attributes, with no implicit attributes.
• Enrich attribute declarations with annotations and support for default values.
• Instead of indicating ellipses depth, simply annotate a depth of 1 as List(Syntax), a depth of 2 as List(List(Syntax)), &c.
• Enrich syntax classes so that they can be treated as first-class data types. (I’ll elaborate in a dedicated section.)

Syntax Classes as First-Class Types

My idea is to make syntax classes more like structs (classes, in Rhombus). This would both simplify writing macros and (perhaps) provide a small performance boost.

Say that I define the following syntax class:

syntax_class Binop:
  ~attributes (left_expr $: Expression,
               operator $: Operator,
               right_expr $: Expression)
  ~description "binary operator application"
  ~patterns:
  | '($left_expr $operator $right_expr)

being analogous to the Racket syntax class:

(define-splicing-syntax-class binop
  #:attributes (left-expr operator right-expr)
  #:description "binary operator application"
  #:local-conventions ([left-expr expr] [operator id] [right-expr expr])
  [pattern {~seq left-expr operator right-expr}])

given some term op_expr $: Binop, I could write '($op_expr.operator) to retrieve the operator attribute and write '($op_expr) to retrieve the original raw syntax.

Thus, syntax that is parsed according to a syntax class are, effectively, converted into a struct of the form

(struct parsed-syntax (raw-syntax attribute ...))

This has the immediate benefit of eliminating the frustrating pattern of having to use define/syntax-parse to reparse syntax stored in some data so that the attributes are again accessible. The aforementioned performance boost would come from eliminating these reparsings.

Finally, since parsed syntax would now be first-class, the attribute form for accessing attributes outside of a syntax template would be unnecessary. One could simply write var.attr.