• 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!