racket
RFC: C-expressions
This RFC attempts to define some concrete syntax for Racket2 in response to issue #3
It is draft and I expect there are some big things that need to be updated, as well as medium things (like better explanations) and small things (like typos).
Please check it out and comment!
The easiest way to read the RFC is at this link.
Overall impression: I like this approach, but I've been assuming there would be an RFC discussing what we want out of an alternative syntax before any proposals for one. @jeapostrophe, were you intending to write something like that as well?
I don't intend to write an RFC about wants. I see some value in that, but I don't know how write it. I think these conversations about wants on the list and issues are valuably fluid. I think that everyone's reactions to some concrete proposal will expose more understanding of wants than just thinking about wants themselves. I'd really like to see someone else come up with an alternative or explain some want that this doesn't fulfill and we can look for ways to improve both and reach a new plateau.
The function and macro examples don't have a ; after the body. Was there meant to be one, or have I misunderstood the grammar/intent?
This is slightly related, but one thing I haven't really understood is why the macro name has to be at the front of an expression. For example, why couldn't you do something like tell the expander to look for the pattern (a and b) and replace it with (and a b). Could this restriction be lifted in something like c expressions? Sorry if it's a stupid question.
@vityou You need to have a consistent rule to know that the macro is and rather than a in your example.
@jeapostrophe wouldn't the expander be able to figure that out similarly to how it knows if an something is a function rather than a macro? Why wouldn't it work so that once the expander encounters a macro, like and that it gives the entire expression (a and b) to and?
@vityou You're saying that when the expander sees a ( it gives control to the first macro that it sees, wherever it is? So (+ 1 a) is a macro invocation if a happens to be bound to a macro in that block. I think that is possible but I don't like it :)
@jeapostrophe I thought it may be helpful if we're moving to a more infix friendly syntax, however I probably haven't figured out all the drawbacks. What problems do you see with it?
Something I think might be beautiful would be a rule like that for situations where you have sequence of tokens but NOT when you have a infix operator (1 + 1) or a function call (f(x, y) --- doesn't depend on whether x or y is bound to a macro.)