PyonR

erable it actually is. It certainly isn't to the point where you could pull in your favorite Python package from PyPI to use in Racket, but it does claim that you can use Racket functions in your Python code at least. The hardest part just using PyPI packages is probably that many of the most important Python packages lean on Python's C FFI, which is a large extra hurdle, though there are many worthwhile packages that are pure Python code. The most successful Racket #langs are languages that fit a particular domain or style of programming better than basic Racket, but that lean on Racket's core semantics and object types as a building block rather than something to be constantly slightly different from in ultimately unimportant ways. While working with Racket, these languages may be very different from the core Racket language, such as documentation languages (scribble), logic languages (datalog), shells (rash), database query languages, etc. If you just wanted to let people write new code for their editor in a language that looks and feels like Python alongside Racket and its #langs, it would be a much easier project to make a language with Pythonic syntax (syntax is shallow), easy constructors for Python-like lists and such (just a few custom datatypes), and a Python-like way of providing generic operators (eg. __magic_method__), etc, but otherwise with semantics closer to Racket's. Frankly, you would end up with a better language than Python anyway, with powerful features that most Pythonistas haven't dreamt of. (Bias revealed!) But I do dream of having a `#lang python` implementation good enough to just use Python packages in a pinch when Racket doesn't have an equivalent package. It's possible, but it's a big enough project and there is little enough manpower in the Racket world that nobody is seriously working on it.

bility with Racket and Python including external modules. And yet, it's a one-man project, written as a thesis and now pretty much abandoned. Writing Rhombus, a mere surface syntax for Racket, should be much easier. The hard part isn't writing it, it's deciding what it should be. The Racket team are the only ones that I can see who are taking all the "write your own DSL" Lisp hype and actually trying to apply it in a structured way. [0] https://github.com/pedropramos/PyonR

[0]: https://github.com/pedropramos/PyonR

r example already write Python in Racket [2], except with full access to all of Racket's libraries as well as Python's. This turns the social aspect to its advantage. Imagine if Python had been written in Racket to begin with - the 2->3 nightmare would have been a non-issue. I hope that eventually, all languages will have swappable syntaxes with a canonical s-expression form, and be distinguished purely by their fundamentally incompatible semantics. We may find we need far fewer incompatible silos that way. Incidentally, and I don't think it's a coincidence, Racket's IDE is the furthest along the non-textual route of any "real" language I've seen. It's very next-gen - you can paste an image file directly into source code, for instance (try it, (define my-image <pasted image>) actually works!). [1] I view all "rites of passage" with suspicion. Like the "rite of passage" of wielding 'rm' incautiously, they usually indicate a human factors failure. [2] https://github.com/pedropramos/PyonR