Names are important, and I am curious about the ultimate name of what we’re now calling Racket2. Changing “PLT Scheme” to “Racket” years ago had some risk, and since that time the Racket brand has been built up. It seems like it would be a good idea to continue building that brand, but I don’t know what that will look like with respect to racket & racket2. Having a clearer idea of that might help ease some of the current angst, and give clearer expectations to folks considering getting involved with Racket. I think it’s pretty clear that there will be some number of people (such as me) who want to continue with #lang racket and some number of people who will want to move to what we’re calling Racket2. It’s great to know there will be nice interop between the two, and it’s great to know of the team’s commitment to continue to support #lang racket, but it would also be great to know how we’ll be referring to the two languages.

I vote for #lang gavagai, where nothing has the meaning you think it has

Although I specifically mentioned the two languages, I’m also referring to the overall brand. For example, the website is http://racket-lang.org\|racket-lang.org, and the first sentence states, “Racket is a general-purpose programming language as well as the world’s first ecosystem for language-oriented programming.” And directly below that we have 6 #lang examples. So I presume we would eventually push the #lang racket example down one (or over one) spot and put #lang ? in the top spot. From my perspective, if #lang racket gets to hang on to its name, then I don’t mind waiting an indeterminate amount of time for the new name, but if we were going to use #lang racket for the new language, then it would be good to know what #lang racket will be renamed to.

Also if the new language will be primary (as implied), then it seems confusing to have the overarching Racket brand that includes a #lang racket language, that’s not primary, along with a #lang ? that is primary.

#lang kerfuffle

or if we are feeling archaic #lang covin

#lang ugly

I don’t need a #lang to write ugly code.

#lang ugly is a suitable name for a version of racket that uses ugly syntax with no possible s-expression or lisp syntax

As an example, if instead of (for/list ([x (in-range 0 5)]) (number->string x)) we had to write for(list((x(in(range(0, 5)))), Number.toString(x))), that would be worthy of #lang ugly

Let’s say we introduce the rule that white space is needed around / and - in order for them to read as division and minus. Also let’s use [] for application and () for grouping. Then we can write: for/list[ ( (x, in-range[0, 5]) ), number->string[x] ]

Still like s-expressions better of course.

I think #lang remix was something like that?

I can’t remember if it was from remix or pyret.

It looks like Matthew already partially addressed this in the “Racket2 possibilities” email: “After another switch, the constructs for racket would remain documented and maintained, in the same way as the constructs for mzscheme and scheme remain documented and maintained, but racket and its documentation would fade to the background.”

I don’t think it’s enough to change the surface syntax and leave the actual structure of forms unchanged

Like if you use just sweet-expressions or a similar reader-level translation layer over for forms, you’ll get something pretty ugly compared to python list comprehension, or Haskell do-notation, or Java 8 stream pipelines.

I’m not sure if this is a good idea, so let me try to toss it here.

Let’s say there are two packages that override #%app. One is fancy-app, which turns (f _ 1 _) to (lambda (x y) (#%app f x 1 y)). Another is reverse-app which turns (f a b c) to (#%app f c b a).

Now, how do I use both? It doesn’t seem to be possible in the current Racket. requireing both will create an identifier (#%app) clash. Also, due to lexical scope, both fancy-app and reverse-app will introduce Racket’s #%app, leaving no room for “inheritance chain”.

Regardless, this is tricky because it’s unclear what (f _ _ 1) means: (lambda (x y) (f 1 x y)) or (lambda (x y) (f 1 y x))?

One way to resolve the ambiguity might be to modify require to import/export identifiers.

(require fancy-app) ; import Racket's #%app, export fancy-app's #%app
(require reverse-app) ; import fancy-app's #%app, export #%app that reverses first, and then does fancy-app later

which is different from

(require reverse-app) ; import Racket's #%app, export reverse-app
(require fancy-app) ; import reverse-app, export #%app that does fancy thing first, and then reverses

Is this a terrible idea?

It’s a terrible idea as-is, but a good idea if fancy-app is defined explicitly with this in mind, with taking a module providing #%app, ML-functor style. That would require fancy-app to explicitly take that an an input and for you to import it something like: (require (fancy-app reverse-app)) to explicitly pass that input

Ah, so that would be:

(require (fancy-app (reverse-app racket:#%app))

vs

(require (reverse-app (fancy-app racket:#%app)))

?

Yeah, those would not be the same thing

But I’m confused. Is the “object” a module or identifier?

and it’s a bad idea to have the order of dependencies affect the meaning of a program this much

but if the ML-functor applications are explicitly written with order, then it’s okay

The more accurate version would be: (require (fancy-app (reverse-app racket)). It’s a functor that consumes a module and produces a module. So racket, not racket:#%app.

And @jeapostrophe already proposes that in https://github.com/racket/racket2-rfcs/issues/75. Cool!

Another potentially bad idea:

One common mistake in macro writing is to duplicate syntax object. It’s bad in two ways: 1) code size blow up 2) unintentional side effect

(the right way for intentional side effect is to stash the expression inside a thunk, give it a name, and use the name several times)

For these reasons, should there be a default restriction that syntax-parse can’t duplicate syntax objects? It should of course be possible to bail out of this restriction.

Duplicating syntax objects is a problem when the syntax object represents an expression, and is put into an expression-position in the result more than once. However, if it’s not as an expression, or at least the “extra” uses are not interpreted as expressions, then it’s fine

maybe instead of a restriction, it could somehow be a syntax attribute or something on :expr?

Or even just a note in the docs about the expr syntax class that this is something you should watch out for when taking input expressions in macros. I had never even thought about it before and didn’t realize it would be an issue.

Look at a simple debug macro for example: (debug expr) evaluates expr to a value, prints expr = value, and the returns value. The expansion of this macro will duplicate the syntax object expr, putting it in two positions: expr and datum. That’s fine.

What’s not fine is using it as an expr twice