We should have syntax parameters

[david-christiansen]

This would make a number of macros nicer to write. See http://scheme2011.ucombinator.org/papers/Barzilay2011.pdf for details.

[gelisam]

With regular, non-syntax parameters, each parameter behaves like Reader, in that the effect of parameterize is to change the value of the parameter during the dynamic extend of the parameterize body.

With syntax parameters, the dynamic-extend of the body of syntax-parameterize is quite short, as it is typically inside a macro definition and thus just returns a syntax object. What makes syntax parameters more useful than regular parameters in this circumstance is that the values of the syntax parameters gets attached to the returned syntax object, so that any macro invocation it contains also sees the values given to syntax-parameterize.

[gelisam]

We discussed the following implementation technique.

The expander's state is divided into two. The ExpanderState evolves over time as e.g. new definitions get added, while ExpanderLocal holds data which would normally be in a Reader if we were processing the tasks as we encountered them, but is instead stored with each task (in ExpanderState's _expanderTasks :: [(TaskID, ExpanderLocal, ExpanderTask)] field) so that we can evaluate the tasks out of order.

Thus, we could attach the current value of all the syntax parameters to ExpanderLocal, and they should propagate correctly from the macro action task which executes syntax-parameterize to the syntax-object creation task which captures those values. That syntax-object creation task might already be associating the ExpanderLocal to the syntax object for scoping reasons.

[gelisam]

In #166 , I suggested the name "ReaderRef" instead of "parameter", to avoid confusion with parameters-vs-arguments. Thus, correspondingly, I would like to suggest the name "SyntaxReaderRef" for syntax parameters, even though the name "syntax parameter" is a lot less ambiguous than the name "parameter".