racket-var doesn't work in reference position

[michaelballantyne]

#lang racket

(require syntax-spec-dev)

(syntax-spec
  (nonterminal dsl-expr
    (dsl+ e:dsl-expr e2:dsl-expr)
    v:racket-var)
  
  (host-interface/expression
    (dsl e:dsl-expr)
    #'#'e))

(let ([x 6])
  (dsl (dsl+ x 5)))

This is probably because it would need to be a special case; Racket variables don't have a syntax-local-value.

And the thinking in the table here shows that we can't actually distinguish all the cases:

syntax-spec/private/ee-lib/binding.rkt

Lines 50 to 60 in 82687f3

	;; situation ; identifier-binding ; syntax-local-value ; syntax-debug-info
	;; bound as syntax ; non-#f value ; environment value ; has matching binding(s)
	;; note: the following two cases can't be easily distinguished; this is why `lookup`
	;; never tells you a name is unbound or out-of-context, and instead can only tell you
	;; that it isn't bound to the particular kind of syntax you check via the predicate.
	;; bound as racket ; non-#f value ; fails ; has matching binding(s)
	;; out of context ; non-#f value ; fails ; has matching binding(s)
	;; unbound ; #f ; fails ; no matching bindings (I hope!)
	;; ambiguous ; #f ; fails ; has matching binding(s)

[michaelballantyne]

A name that a DSL author thinks of as "Racket variable" could also really be a rename transformer or an identifier macro, e.g for contracted names.

To address such names, I think we'd have to make the criterion be "is it an identifier that expands successfully under local-expand?" We would have to catch syntax errors raised by the expansion and consider this failure to indicate the syntax does not "parse as a racket-var".

This would come with its own drawbacks though:

• Names with syntax-spec binding classes that have reference compilers could expand as racket-var, which would be surprising.
• Repeated expansion (and repetition of expansion side effects) would occur if expansion succeeds but we discard the result and re-expand when the same name appears in the DSL compiler's output.

Given that a "racket variable" may expand to an arbitrary expression anyway, I think it probably makes sense for users to just use racket-expr, and if they want an identifier position, to use a rewrite to a form with racket-expr.

[michaelballantyne]

The above suggests that maybe we should make it an error to include racket-var in reference position in an sspec.