consider a complex form `let`

[dannypsnl]

Traditionally, we can write

(define-language L0
  (Expr (e)
    (let ([x e] ...)
      e ... e)))

The problem in typed-nanopass is, if we write the following

(define-language L0
  (Expr (e)
    (let ([,x ,e] ...)
      ,e ...+)))

What was the type of L0:Expr:let?

The point is how do we ensure the difference between meaningless S-expression syntax and the code that really needs a field to store?

I have a draft idea about what the target should be.

(struct L0:Expr:let
  ([bindings : (Listof (Tuple Symbol L0:Expr))]
   ; how to judge no empty?
   [body : (Listof e)]))

Update 2022/09/04

I think the problem is I'm trying to fuse two concepts within one syntax, the new draft idea should be:

(define-language L0
  (Expr (e)
    (let ([,x ,e] ...)
      ,e ...+)
    #:type (Let ([(cons x e) : (Pairof Symbol Expr)
                 [e : (Listof Expr)]))))

A structure syntax is

(type-name
  ([field-construction-template : Type] ...))

This means the macro has an ambiguity now, however, the macro has no idea which e it is.

[dannypsnl]

I think ... form is not an accident, it really points out multiple patterns share the same cardinal, hence ,@ is not a good replacement for ... since ,@[x y] is more confusing than [,x ,y] .... Under this solution, , is just a mark to tell the macro to ensure it's a variable, and ... stands for (List A).

And the structure definition generator should be modified to fit.