> On Jul 16, 2019, at 15:32, rocketnia <roki...@gmail.com> wrote: > > I find it worrying that racket2 would be kicked off with infix syntax > (something which I think of as an unnecessary sticking point in the way of > prospective macro writers and language designers, and hence a move *toward* > elitism *as opposed to* welcoming everyone)
I think this fear is natural and understandable, but I want to take a moment and urge everyone to think bigger than that, even if we as programmers are often trained not to. Do not think “because we are moving to a syntax for which macros are harder to express, the language we create will have an inferior or more difficult to use macro system.” If we were setting out to responsibly engineer a new language on a deadline, that thought would be right on the money… but we’re not doing that. Racket is a research language, from an ever-growing community full of very smart people who have produced lots of quite significant research results. They have taken problems that used to seem untenable and made them perfectly achievable (and indeed, often achieved!). So instead of thinking about all the ways Matthew’s proposed syntax is a compromise that necessarily comes with certain downsides, think of it as a challenge: how do we take all the lovely things we’ve come to enjoy and take for granted in #lang racket and do them in a language with a less regular syntactic structure? How do we make writing great macros as easy in #lang racket2 as it already is in #lang racket? That means figuring out both what the primitives are and what the DSLs look like—syntax/parse did not naturally follow from hygiene and syntax objects, as much as it sometimes feels that way. I am not saying it is easy, and I’m not saying it’s even guaranteed to eventually succeed: perhaps we will fail. But I don’t think we have any reason to suspect we will just yet. It can’t start by being everything we want it to be, of course; things take time. I just think that thinking about things as such a stark dichotomy is disingenuous and self-defeating. Obviously, we should not aim to become more elitist, on any axes, so let’s aim not to be. This is time for pie-in-the-sky brainstorming, not risk management. Having existing research to build on helps, but even that isn’t required. So although I know firsthand how hard it can be as an software engineer to think about what we want without worrying about how we can build it, let’s be aspirational and exploratory for a bit. Alexis P.S. If your qualm with moving from s-expressions is one of aesthetics, not ease or ability, I admit I can’t argue with you there. But I don’t imagine those kinds of discussions are likely to go anywhere productive, anyway—see Wadler’s law. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/B0910168-AB4F-43B7-A690-B01281CC8E59%40gmail.com. For more options, visit https://groups.google.com/d/optout.
