Hello, community! Let me tell a few words about the idea of transitioning Racket to a traditional syntax to gain popularity: I think this idea is a fallacy. Racket is not popular due to its s-expression syntax, because Clojure has such a syntax, and still, it seems popular. So I don't think such step will raise the adoption of Racket.
There is nothing new in having a traditional syntax language with Lisp-like macros. There is one, it's Elixir. Note that I have lots of experience writing complex macros in Elixir, and I expect writing macros in an s-expression language to be much easier, simply because in such a language, its notation and its AST are isomorphic, i.e., they share the same syntax. Let me explain this: in Elixir, sometimes, the way to verify if a macro generates the code we want, is to see what this code's AST looks like, which in Elixir is a kind of s-expression (yes!), and from this, infer how to build the AST inside the macro using the Elixir notation; this effort is totally unnecessary in languages in which the notation and the AST are the same thing. In short: Clojure is a popular s-expression language on the JVM, and Elixir is a popular Lisp-2 language on the ErlangVM, consequently, the `Racket 2` language will contribute nothing to Racket's wide adoption. In fact, I think it will be a strategic mistake, if popularity is all about. Does Racket wants to be popular in the industry? Then Racket must focus on being a language-oriented programming ecosystem on a popular VM, like the ErlangVM, the JVM, and the WebAssemblyVM. This means to stop working on the RacketVM, if there's such a thing, and to start moving Racket's language-oriented programming features into these popular VMs. I don't think that having a kind of Elixir++ on an unpopular VM, will make the industry adopt such a language. For example, I would love to see Racket become a statically typed Lisp-like language-oriented programming ecosystem on the Erlang VM. I am sure if this ever happens, there will be hordes of programmers jumping immediately into such ecosystem. (Ehh, I think the Shen language is the closest thing there is, but oh my, nothing can have a more terrible marketing strategy than that of Shen). To conclude, I wish a great future to Racket, and will continue following its future development. Ah, I like the Hackett idea also, very very interesting, and promising direction, but again it needs to target a popular VM. Best Regards, Mário Guimarães Em domingo, 14 de julho de 2019 18:44:30 UTC+1, cwebber escreveu: > > The context of this email is the proposal by Matthew Flatt that we move > to an easier-to-accept surface syntax for #lang racket2. > > Matthew Flatt has heard more than enough from me of concern about this > proposal. But I should indicate that I'm highly sympathetic to the > goal. I would like to lay out the following observations: > > - The challenge with s-expressions is largely in anxiety with something > that looks extremely alien. I suspect there's more fear from > instructors than students in encountering a lisp syntax; my > experience is that introducing someone who doesn't know differently > to a parenthetical syntax isn't scary for them, and they tend to like > it. But people who have *started out* with experience in a non-lispy > language tend to find it scary. > > - Nonetheless, assumptions that various math operators should be infix > is understandable because that's what people see today. > > - I am indeed very for growth in the community, though my main interest > in growth is in seeing a wider diversity of participants than just > raw numbers. Obviously other peoples' mileage may vary. > > - We are at serious risk in this pivot of losing some key things: > > - Many communities I have been in that have undertaken such a large > pivot to increase popularity expend enormous energy in the move to > the new thing, and in that process, the project actually collapses. > What I'm trying to say is that a pivot is a gamble; we should > calculate our odds carefully. (Indeed, the first thing I thought > when I heard that this might happen was, did I make a mistake in > shifting my work to Racket? It is unlikely I would have come to > Racket if there wasn't an equivalent amount of elegance.) > > - I'm not sure if I could have understood Racket Week with a syntax > that didn't have the elegance of s-expressions. This is not to say > that *no* syntax can have that level of elegance where things can > be so clear, however. > > IIRC Matthew's proposal for "#lang racket2" was something like the > following: > > a) function(args ...) should work. > b) infix is necessary for math, such as 3 + 4 > c) parentheses should be possible for grouping > > The weird thing about the last one being that this is already kind of > true in s-expressions, but by ~default this also results in application. > > Let me add one more suggested design goal: > > - the new syntax should must not be significantly less elegant than > s-expressions. > > Is there a way to achieve this? I actually think the best path forward > is to have a surface syntax that actually maps completely to > s-expressions, which is in fact universal that it can work with *any* > s-expression syntax. > > I would suggest starting with Wisp as the basis for examining this: > > https://dustycloud.org/blog/wisp-lisp-alternative/ > https://srfi.schemers.org/srfi-119/srfi-119.html > > Sweet-expressions may also be an alternative to explore. However, I > think Wisp is a more elegant base; it can transform *any* wisp code into > s-exp code. Not discussed in my blogpost about Wisp is that it also > supports infix via {3 + 4}. So ok, now we have that. And we can still > group: > > {3 + {8 + 4}} > > So that's points b) and c), but we don't have a) yet. Could we add it? > > I think we can extend wisp with one thing and get everything we want: if > you have func(arg1 arg2 arg3) where the parenthesis comes *immediately* > after the symbol, that is rewritten to (func arg1 arg2 arg3). I will > call this version ~Wisp. > > With all this, observe the following code rewritten from Scheme to ~Wisp: > > (define (rgb-maker mk) > (lambda (sz) > (vc-append (colorize (mk sz) "red") > (colorize (mk sz) "green") > (colorize (mk sz) "blue")))) > > define rgb-maker(mk) > lambda(sz) > vc-append(colorize(mk(sz) "red") > colorize(mk(sz) "green") > colorize(mk(sz) "blue")) > > Here is another chunk of code, taken from HTdP2: > > (and (or (= (string-length "hello world") > (string->number "11")) > (string=? "hello world" "good morning")) > (>= (+ (string-length "hello world") 60) 80)) > > To: > > and(or({string-length("hello world") = string->number("11")} > string=?("hello world" "good morning")) > {{(string-length "hello world") + 60} >= 80}) > > And in fact the latter can transform itself *directly* into the former. > And the former technically is also still valid Wisp: you can embed > s-expressions into it and they still work. > > I think this satisfies the requirements that Matthew laid out. > > There's another major advantage of this. We can now write languages > that work either like: > > #lang s-exp "mylang.rkt" > > or: > > #lang wisp "mylang.rkt" > > The main thing that Wisp is missing right now is editor tooling so that > doing indentation is convenient. But that's more than feasible to add, > imo. > > I think this is the best way to move forward without creating > significant divisions, throwing out valuable things we have, or making > future Racket Week courses all that much harder. What do people think? > > - Chris > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/1b105796-de37-4cd3-85af-7be4af3a8421%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
