Long-term bridge for Rhombus-to-Racket

[benknoble]

• With apologies if this already being discussed elsewhere!
• This might make a better fit for "Discussions," I'm not sure.

The question of Rhombus interoperability came up recently in Discord. Consider this question (anonymized):

I've spent a lot of time working on the Rhombus pict library. I think it's a lot better than the Racket pict library, but I have no expectation of backporting the Rhombus library to Racket or to S-expression syntax. So, that makes the library a "new feature" with no S-expression syntax.

[@badkins] Excuse my ignorance (I haven't been following Rhombus), but can a #lang racket module simply (require <name of Rhombus pict>) to use the superior Rhombus pict? If so, then it seems the main disadvantage to an s-expression lover is that to contribute to the Rhombus pict library, they would need to work in Rhombus syntax. Hmm... I just checked out the docs, so a second disadvantage is having the docs in Rhombus syntax.

The replies indicate

• No: the Rhombus pict library makes extensive use of dotted methods which don't have an analogue in Racket.
• That's disappointing

• the issue is just that Rhombus and Racket are fairly different languages; it's not just Racket with a different syntax. Similarly, if you look at Hackett, you aren't going to be able to use typeclass methods easily in Racket because the relevant concepts just don't translate over.

  More generally, I think the way to think about it is that Rhombus is a new language built on top of Racket. Some such languages work hard for two-way interoperation (like Typed Racket) and others don't (like Hackett).

It's not that we actually believe Racket has been adversely affected Rhombus (au contraire!), but there is some perception that Racket has matured to the point that new investment goes primarily into Rhombus.

The real question

I posed a question in reply to the above discussion:

Would a better Rhombus-to-Racket bridge help? I wonder if that’s something that’s easier to package once Rhombus settles (more), but I just don’t know enough about the current state. Sam’s comment made it seem like there is no way to use rhombus/pict, for example, but maybe there’s a way to have a dot Racket macro that does some of the right things, or a way to expose some Rhombus names in way that makes sense for Racket consumption (without all the dot stuff, if that doesn’t map well). Just spitballing.

Of course, "different languages are different things," and while some have great interoperability, others need not.

And yes…

• But it would be nice to have a Racket require sub-form that could import dot members from Rhombus namespaces and classes

• I remember hearing that one of the promises of developing in racket is that different modules could be developed in different languages and they could all interoperate. Sounds like that's not true if rhombus pict can't be used from lang racket.

• My understanding now is that It can be true but depends on the language. I'm guessing it's possible to export stuff from rhombus for use in racket, just not always.

So, what can we envision about a world in which Racket users can get some of the goodies of Rhombus-style libraries?

Or is it the case that all Rhombus libraries will be so tied to something about Rhombus that they can't be made useful in Racket? (I don't think so, but arguments in either direction are probably useful.)

Some initial considerations

• I'm willing to give up some of the niceties of, say, fluent interfaces that come from having . work. I think a Rhombus-aware threading macro (👀 Qi support?) could alleviate some of that pain.
• … what else? As a non-Rhombus-user at the moment, I'm not sure what else to add!

[mfelleisen]

On Jan 29, 2025, at 6:46 PM, D. Ben Knoble ***@***.***> wrote: that "I remember hearing that one of the promises of developing in racket is that different modules could be developed in different languages and they could all interoperate.” (I am not involved with Rhombus so that the rest with a grain of salt.) My Racket manifesto, presented at some RacketCon, stated the above as a goal and provided (a tower of simple) examples. As you correctly point out, this is a non-trivial goal and indeed, we have failed time and again in various ways to get even close. Consider `#lang lazy`. I “spent” one dissertation on the goal of getting the interaction between `#lang racket` (in various flavors) and `#lang lazy` right. Put as motivating questions, why shouldn’t I be able to use `length` to count the number of elements in a finite stream? Why can’t I use `map` to apply a function to each element of such a stream? — Stephen and I got good results but none brought us close to what we aimed for. Bridging the gap between languages seems to require brute-force coercions and I am not sure it pays off to deal with those. If you have an infinite amount of time, read up on the papers that discuss “gradual typing” or “mixed-typed programs” or “optional typing” and what we called “migratory typing” for a while. In essence, this limited-area version of the question seems to kill too many trees already; I am not sure we can hope for an “easy” interop solution in general. So I think this is “I am sorry I had such high hopes back then” message. We need tons of research to get this right and I don’t see it happening, even though Racket offers an almost ideal grounding for it — Matthias

[benknoble]

In reply to

I remember hearing that one of the promises of developing in racket is that different modules could be developed in different languages and they could all interoperate. Sounds like that's not true if rhombus pict can't be used from lang racket.

another user wrote

The big-picture story is that modules written in different languages definitely do interoperate.

How exactly that interpretation works depends on the languages involved. At one extreme, #lang info intentionally has extremely limited interoperability, because we don't wasn't metadata files to run arbitrary code. With #lang web-server, most of the time things interoperate totally transparently, but there are a few scenarios that need attention: a better approach to capturing continuations inside callbacks to untransformed higher-order functions got a research paper (https://blog.racket-lang.org/2010/10/the-two-state-solution-native-and-serializable-continuations-accord.html). Typed Racket has interoperability as a core priority, but it also has to preserve the invariants of typechecked code, and the contracts to do so impose a performance cost that can be problematic in some cases. This has prompted a whole bunch of research papers. Algol 60 just didn't implement much interoperability, because it's mostly about the fact that you can run Algol 60, not a suggestion that you write libraries in Algol 60. The RnRS languages have a different definition of pair?, which is occasionally annoying. Slideshow and the Scribble-related languages have no interoperability problems.

In all of these cases, though, the languages share the same notion of modules and instantiation. They exist within the same universe, and they can interoperate as closely as they want. Languages with similar semantics interoperate for free. When languages have different semantics, they sill can interoperate, it just takes design and implementation work to figure out what interoperating should mean.

---

Separately, the following reply was posted:

I think it's important to remember here that Racket's stance on backwards compatibility is not changing. If core libraries migrate, they will do so in a way that does not affect existing clients. If documentation changes, it will do so in a way where clients not using rhombus syntax don't have to read documentation in that syntax. Figuring out how to achieve those things is definitely in scope for the Rhombus project. In fact, the multi-language documentation issue specifically is something that we've been looking at recently. (Matthew is exploring a "language family" system for Scribble, for example.)

Racket is a programming-language programming language. Solving problems related to seamless interoperation and reuse across languages is this community's specialty. I trust in that goal and think we're exceptionally well equipped to tackle it.

Yet there is still concern from @badkins as an "industrial user" about the shift in focus.

To which we have

I think my disagreement here is the idea that there can be only one main focus in a community of our size. Racket's unique features allow developers to focus on non-racket languages and improve the core language and runtime for everyone else simultaneously. We've already seen that with Rhombus: treelists, #:do blocks in for loops, raco demod improvements, amalgams, various core performance improvements to module load times. These are all new developments for #lang racket users that would not have happened without Rhombus. This has happened with other languages too: Typed Racket motivated improvements to the contract system for all Racketeers, and Scribble gave us the ability to use @ notation in Racket via #lang at-exp racket. Racket's history is littered with core improvements to the lives of ordinary Racketeers coming from development on non-Racket languages. That is the power of a programming-language programming language.

[jackfirth]

We added the veneer feature to Rhombus to make it easier to reuse ordinary Racket data types in Rhombus's dot-accessor system via a light wrapper. I think it's reasonable - especially once we have some Rhombus libraries that don't already have analogues in Racket - to explore language features for going in the other direction too.