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 racket-users+unsubscr...@googlegroups.com. 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.
