@rokitna What would be the need for such a transpiler if we already know that #lang racket will coexist with whatever comes next?

I think it’s for people who prefer S-expression but want the features of Racket 2 that are not compatible with #lang racket (assuming that Racket 2 has non-S-expression syntax).

What sort of features would that be? I’d assume you’d still be able to require the new libraries in #lang racket

Oh, I don’t know that there would be any immediate practical reason to have it. I just figure someone will make it to prove a point, to show they can, or to prepare for the day there is a practical reason for it.

But yeah, it’ll become practical mostly only if Racket 2 ever has any (semantic) features that are particularly hard to achieve in #lang racket.

It wasn’t my intention to imply there was any reason other than proving a point. :-p I have my reasons to like s-expressions, and many other people have theirs, and it seems like someone along the line will find it useful rhetorically as a way to

• reassure s-expression users that #lang racket doesn’t need to have a parallel implementation of every Racket 2 system, or
• prove that some Racket 2 idea is feasible or even better with s-expressions.

And for that matter, yeah, Racket 2’s syntax direction is up in the air, and some of the ideas would make it possible to write Racket 2 programs using s-expressions without this kind of translation layer.

#lang s-exp racket2 :stuck_out_tongue:

@notjack yeah, what @rokitna said. For instance, I think supporting define* (https://github.com/racket/racket2-rfcs/issues/46) would need a change to the macroexpander. I can’t simply require a library to get this feature. In this particular case, I think it might be possible to backport the feature to #lang racket without breaking any backward compat, but in general, it might. Hence the new S-expression language.

I think we should find a way to make (automatic) define* something you can import with require. Perhaps by adding some sort of #%local-definitions hook that gets inserted into internal definition contexts and which modules can override the same way they can override #%app. Personally I’d love to use that sort of hook as a way to implement a linear type checker.

@githree I’ve encountered some of these issues in my work on Digital Ricoeur, and I’d be happy to talk about them further. We’re still very happy with our choice of Racket for our web server and as the backbone of our whole toolkit. You’re right, though, that there are a few areas where libraries are missing: NLP is a big one for us, too! And rolling our own at production-quality is not a viable choice there.

I think part of Racket’s “ecosystem” is shared libraries (e.g. C) at the OS level, accessed through the FFI. We’ve been working with that in some cases. IIUC the Julia languages uses this approach to link in Python as a shared library.

Currently, I’ve been working with a Python NLP library (spaCy) by running a Python process through Racket’s system* and communicating over standard IO. I’m very pleased with how this is going so far: I have raco setup manage the Python dependencies & environment (via miniconda), and I’m integrating the Python docstrings into the Scribble documentation. I hope to have some of this work out publicly soon.