Long term, it probably makes sense to add a racket2 mailing list.

I agree. Until I read @notjack‘s message, I didn’t understand this, at all. Why would you lower a barrier to entry, unless you wanted more people to use it? Effectively how is that different from ’more popular’?

The way @notjack phrased it, it’s actually addressing a question I asked, about who are we aiming for and how popular (sorry) do we really want Racket to be?

IIUC it’s saying, there are people who are interested in Racket, start to try it, and the parens are just too much. We want to keep those people.

I mean, honestly, I’m having trouble visualizing who those people are. I’m really curious to learn more about that. But, I mean, at least it’s moving in the direction of having a more-specific picture of who we’re aiming at. What attracted them to Racket? What including but not limited to the parens pushed them away?

Having that picture is helpful to guide people doing the work, and, to help explain the work.

Like, did some of these people know going in that Racket used a lispy syntax, but were so interested in possible benefits X Y Z that they started to try it anyway? If so, that is super interesting.

It’s not just about eliminating objections/negatives (which IME is rarely sufficient; instead it’s usually a never-ending game of whack a mole).

It’s validating what the positive things are, that are attracting people.

So, how can we make those even better? How can we get the message out, about those, even more effectively?

Which I think in the end is where any real growth comes from.

https://racket.slack.com/archives/CLKGAC44X/p1563810853066400 @mflatt What if a Chez->WASM compiler existed? Or some of us could cause it to exist, through some combination of finding funding and hands-on working? Would that make Racket->WASM much easier, or just a little? (I know you’re super busy, I’m just brain-storming, and definitely not asking you to make anything but a seat-of-the-pants, no-promises guesstimate.)

My best guess is that Chez->Wasm is the way to go. The reasons in favor should be clear, so here are some reasons I might guess wrong: Wasm isn’t actually an assembly language, so the work of making Chez Scheme view Wasm as a back-end might be counterproductive. For example, Wasm will have its own layer of optimizing compiler, so spending a lot of effort on register allocation might be a bad idea. Similarly, trying to simulate jumps when there is no goto or tail calls might be the long way around; there might be a better way to represent continuations.

@greg ^

Even if Chez->Wasm isn’t the right idea, implementing something that looks like Chez Scheme to the rumble and schemify layers is almost certainly the right idea.

Thanks! That’s interesting. Just throwing around buzzwords, I guess another idea is Racket->X->LLVM->WASM ? But X isn’t Chez, and maybe never will be.

Yes, could be. Using LLVM would probably mean distinguishing between ahead-of-time compilation and on-the-fly evaluation (through maybe just an interpreter), which could work for many things.

WASM tail calls are already in implementation phase: https://github.com/WebAssembly/proposals/issues/17

Tail calls would be a big boost to Wasm as a backend for Chez Scheme!

I believe the consensus is: there will be tail calls in WASM… just a matter of when.

@mflatt @greg it looks like it is already as an experimental flag in Node 12: https://github.com/google/schism/issues/5#issuecomment-511042506

There are also proposals in the works for better gc support. Right now, a language that wants it provides its own gc and uses a shadow stack. And while that’s fine for some uses of wasm, it’s bad for, say, the browser, which already has a gc. If you have code from N languages running in the VM with N different gcs, that’s… not wonderful. But the initial gc proposal doesn’t include stuff like weak references or finalization, so I think it will be awhile before it gets serious use.

Andreas Rossberg has also mentioned that he’s like to generalize the exception-handling proposal to support delimited continuations, but that’s also a ways off.

FYI, I expect many are here because of syntax. The main thread for that is here: https://github.com/racket/racket2-rfcs/issues/3 — although it shows up in other places too

@badkins I can’t speak for everyone in the core team (we have not had any secret meeting about these issues where there’d be such a message concocted), but I’ll give you my opinion.

Will there be a hidden link? — If Racket2 is significantly different than Racket1, then there will be new docs and the old docs will be available and maintained. You can see an example of this from PLT Scheme v372 which we released 12 years ago and deprecated at some point (I forget when) by looking here: https://docs.racket-lang.org/mzscheme/index.html This page is listed in the top-level TOC under compatibility and if you search for a binding in it (like #%module-begin) you’ll see an entry for mzscheme but if you are in DrRacket and press F1 on an identifier in #lang mzscheme you’ll only see the entry for MzScheme. If Racket2 is not significantly different, I expect we’ll have a dual view documentation system.

What will support look like? — Racket2 and Racket1 will share the same VM and the same primitives, so security and performance improvements will automatically be shared. (It is highly likely that Racket2 will be implemented in Racket1, so it will be necessary to improve R1 to improve R2.) Similarly, it is very unlikely that useful libraries like openssl or web-server would be rewritten; instead, I’d expect wrappers to be provided for their macros to make them work in the new system. Eventually, I can imagine the main implementation of the macro switching to R2 and the R1 being the compatibility one. Again, since the actual runtime would be shared between R1/2, any improvements or fixes would be shared as well. The only plausible kind of thing that would not be improved (IMHO) would be things like adding extra features to a core R1 form. For example, over time, features have been added to struct in R1. I can imagine a feature being added to R2’s version of struct and not backported because it relied on too much R2-specific stuff. It’s hard to imagine what such a thing would be concretely though, because we don’t normally do stuff like that anyways (it would be backwards incompatible) and that’s why I’m interested in R2 anyways.

We will always be interested in helping users who are programming in #lang racket. Right now, we routinely answer questions on the mailing list about R5RS, which is 21 years old next month.

I value industry users of #lang racket. I welcome all programmers on languages in the Racket ecosystem, even filthy users of Typed Racket. :stuck_out_tongue: In my opinion, the problems that might be caused by two communities are exactly the kinds of technical challenges I am excited about solving. The main issue I see is (a) how to ensure data can go back and forth between R1/2 and (b) how to ensure macros are usable in both. (a) is actually easy, but we have to remember to do it. (b) is more complicated, but I think we know how to do it too.

I don’t perceive thoughtful people like you as intolerant nuisances. I do think that many users seriously underestimate our commitment to backwards compatibility. Here’s a random example: Take this code from 15 years ago — http://www.cs.utah.edu/plt/kill-safe/code7.ss — to make it run, you need to change any? to any/c and the object-waitable? to evt? (Those changes were noted in the change log from March 2005. So if you updated the code after seeing the change log, it would still work 14 years later.) This example indicates that we’re not perfect, but I believe we try far harder than almost any other language implementation team.

Finally, I definitely think it is a big deal, but it is extensions and expansions like this that has made Racket attractive already. Language oriented programming would not be as effective with the original macro system and it was a good thing to throw it away as the main way to do things. Modules (added in 2002) are far far better than the units we had back in 1995, but units are actually still supported and used.

FWIW, I don’t think there’s anything wrong or in bad faith with your posts and questions. I feel a tiny bit like we’ve tried to answer it the same way many times. It is tempting to think you don’t believe us, but as a technical and persuasive writer, I am forced to blame myself and try again.

:heart:

Thanks Jay, I appreciate the time for that response, and it’s the most direct addressing of my concerns as I’ve had in the past couple weeks. It’s not that I don’t believe you about the commitment to backward compatibility, it’s that the messages, and subtexts, have been a bit fluid. I have to say, you had me at “filthy users of Typed Racket” :wink: