considering how much commotion the announcement has caused so far I have a very fitting working name proposal #lang ruckus

I just thought this in here; leading sigils like scribble at-exp are the first thing that comes to mind for algebra style function notation: @foo{blah blah blah} reads as (foo "blah blah blah")

((get-my-fun a b) c d) becomes @get-my-fun(a, b)(c, d). add that to the free use of parenthesis for grouping and @get-my-fun(a, b)(c, d) can also be expressed as (@get-my-fun(a, b))(c, d)

I’m not clear if this works with the goal in @mflatt email; >>* Any new syntax must specifically preserve Racket-style language-oriented programming, which means everything from defining simple pattern-based macros to building whole new #langs with a smooth path in between. Again, our current macro technology must be an enabler for a new surface syntax, not a casualty. <<

Make an RFC for Matthew’s 3 syntactic principles’ at https://github.com/racket/racket2-rfcs/issues/3

`Racket2’ is a temporary name

Matthew had a slide about the racket2 name. TL;DR: don’t panic. Hasn’t been decided whether the new #lang will be called racket2 or something like rhombus or ruckus or whatever.

There needs to be an RFC for name selection. I’d suggest minimum criteria of; easy to spell, easy to search, cheap domain name that isn’t too obscure (I paid for a .name domain that gets rejected by email validation scripts)

lang ¯_(ツ)_/¯

(unfortunately illegal :disappointed:)

I think we can get something close to algebra-style functions f(expr1, expr2) and grouping-parens (expr) if we get rid of zero-argument functions and add tuples. Make f x y mean applying f two the two arguments x and y Make () mean the empty-tuple or unit value, so that zero-argument function can be approximated by f () Make (expr) mean the same as expr in all cases Make (expr1, expr2, ...) mean a tuple, so that if people want to they can use f (x, y), passing arguments in a single tuple However, we should not do anything to disallow (f x y) as a function call.

see, this needs to be fixed, I want to at least be able to have #lang ☕

The algebraist in me applies functions from the right :wink:

Hello! Here’s my take on the topic of this channel: https://groups.google.com/d/msg/racket-users/ewWuCvbe93k/ocbpQeB9AQAJ

> 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. > > Cheers,