unseemly
unseemly copied to clipboard
paulstansifer
Allow interpolation of identifiers
We currently allow manipulation of Pat, Expr, and Type syntax; we need to be able to manipulate Atom (or maybe we should call it Ident -- I've never really decided whether VariableReference is a wrapper around Atom or a separate thing) in order to write something like:
'[Expr| .[ ,[my_var], : Int . (plus ,[my_var], one) ]. ]'
In fact, I don't think it's possible to have n-ary function definition without this feature. (Or allowing functions to take patterns instead of parameters as input).
The trouble is that, if I'm writing (plus ,[my_var], one), how does the parser know whether I'm interpolating an Expr or an Atom? This is a syntactic ambiguity.
One option is to structure nonterminals such that Pat → Atom | ⋯ and AtomNotInPat → Atom; then Pat and AtomNotInPat could both be safely extended with ,[ ],. But then, if the author of a lambda macro forgot to use AtomNotInPat, they've laid an ambiguity trap. I think this strategy only works well enough for a temporary solution, but a temporary solution will do for now.
For the long-term solution to this problem, maybe we say that, if the grammar goes Nt1 ::= Nt2 | …, then Nt2<T> is a subtype of Nt1<T>?
The type system can’t solve a parsing problem! (Well, in Unseemly, that’s not guaranteed to be true, but it’s true here.) The parser still needs to know what interpolation to parse it as.
Buuuut.... if you did have this rule, you could also say that you only add an interpolation for the “top” nonterminal of any hierarchy. I think that probably would just do the right in most cases!
The simple solution is implemented, I think, but there's an exciting ICP that happens in beta.rs when freshening .[ ,[name], : Int . five].. Everything about bound_from_beta looks super-wrong, but maybe I'm misunderstanding it.