Could Racket be used as a "frontend" for a non-Racket language?

[Ryan Kramer]

I have no plans to work on this, but I am curious if this has been discussed or attempted...

Motivation: My job has been C# for many years and while C# is very appropriate for most of the problems I encounter at work, sometimes a problem comes along that makes me want more power. In those situations, I think the language I want is "C# except now it's S-expressions and it has Racket's macro system."

And then I wonder if an alternate version of C# could be implemented this way:

1) Create a new grammar for what a fully-expanded C# AST is. This will be in terms of Racket syntax objects, just like Racket's definition of a Fully Expanded Program.

2) Write a compiler that generates CIL (the bytecode) given a fully-expanded C# AST.

3) Use Racket's #lang mechanism and macro system to implement the surface language.

Now this new C# could borrow a lot of power from Racket, right? For example, I could make all of Racket available during expansion! Even if I don't want C#-the-surface-language to have macros at all, why shouldn't I keep the Racket-powered backdoor open? As long as you generate a valid C# AST, I should be able to compile it for you.

The #lang mechanism and Scribble are two other nice things that could probably be adapted into the new C# if desired.

I can understand why Microsoft wouldn't do this. But I've seen enough hobby languages, and I'm surprised that none of them do this. Reusing a backend (like dotnet or the JVM) is common, reusing a "frontend" is something I've never seen. Is Racket's macro system too specific to Racket's definition of a fully-expanded program? (The little bit I've done with local-expand and stop-ids makes me think it would work fine.) Is there something else that would make this approach more trouble than it's worth?

[Raoul Duke]

nice, yes, I've long wanted that, in general. Like, I want to use
{erlang,ADA,haskell,typescript,go,...} but with s-expr's and macros.

One could instead perhaps leverage Graal and things like ABCL or
Clojure? You could in theory use something like XMLVM and Clojure to
at least cover C#/.net and Java. (because another layer of indirection
in a programming tool chain is never a problem, nope.) Or one could
perhaps make a gcc s-expr front end https://superuser.com/a/1198792
and somehow leverage gcc's RTL to intermix-ffi with other languages?
no idea. in this day and age i guess llvm is better? i'm a static
typing lover, and some of the languages I'd like to see targeted are
statically typed, so ideally it would be maybe something like TR
supporting the target language type system, which probably is too much
like square peg round hole -> unless one falls back to Xtend-esque
approach which would compile to source code in Java/C# and then use
the "native" compiler to type check.

???

[Robert Calco]

Check out IronScheme... it may be just what you're looking for.

- Bob

--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/cc7c1792-ba59-400f-856a-3bb02a6096fbn%40googlegroups.com.

--

Bob Calco

bobc...@gmail.com

813-997-3583 (work mobile)

813-523-3751 (personal mobile)

"But you can catch yourself entertaining habitually certain ideas and setting others aside; and this, I think, is where our personal destinies are largely decided." -- Alfred North Whitehead

"And now I see with eye serene the very pulse of the machine." -- William Wordsworth

[Philip McGrath]

I haven't done much with this personally, but a few pointers in Racket:

• Urlang uses Racket's macro system as a front-end for JavaScript (in the way you discuss with C#, not compiling Racket to JavaScript): https://github.com/soegaard/urlang
• Alexis King's Hackett is an experimental Haskell-like `#lang`: https://lexi-lambda.github.io/hackett/ While it currently only runs on the Racket runtime system, Alexis' blog post, "Reimplementing Hackett’s type language: expanding to custom core forms in Racket", discusses the possibility of an alternate backend targeting GHC and goes into extremely useful detail about implementation techniques that can help: https://lexi-lambda.github.io/blog/2018/04/15/reimplementing-hackett-s-type-language-expanding-to-custom-core-forms-in-racket/
• The recent paper "Macros for Domain-Specific Languages" (https://dl.acm.org/doi/pdf/10.1145/3428297) presents a high-level API for doing many of the things the aforementioned blog post implements by hand. (Alexis is a co-author on the paper.)  The `ee-lib` library provides the API discussed in the paper: https://docs.racket-lang.org/ee-lib/index.html (I have done the by-hand approach to custom core forms, and I'm excited to try the new library.)
  

-Philip

To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAATHPo3MJDtgxrt3FKPTRvt-avaniq4LTwF6VH_SSe%3DvAV3V4A%40mail.gmail.com.

[Stephen Foster]

This is one of the main ways I use Racket -- but as a front-end for JavaScript, not C#.

[Ryan Kramer]

Thanks everyone for the good reading. I haven't fully digested it all yet, but Alexis' blog is extremely relevant and shows that this approach is not as close to a "free lunch" as I thought it might be.

[D. Ben Knoble]

No idea if this is what you're looking for, but I have a feeling it wouldn't be terribly difficult to design a #lang where modules were programs that, when run, output C# code (kind of like how scribble & pollen can output HTML). Then you could have a language (w/ or w/o) macros that gets run down to C# and let the C# compiler and project toolchain take care of the rest? Essentially it's only a syntax—the semantics is "turn it into this C# code."

[Sage Gerard]

Short answer: Yes...ish. I wrote a few code generation programs.

It can happen, but the Racket program would be dependent on the target language's toolchain and standard library. Before we get to that, note that not all languages cleanly translate into one another (Some scripting languages actually have features that introduce forward-compatibility problems, see JS and with).

The standard library issues become more apparent when you realize that Racket programs have defined value types where other languages don't bother (e.g. complex numbers and path types).

If your goal is to generate a few well-defined programs its fine, but if you want a completely correct model for translations with a DSL as a front-end, then that can be a pretty large undertaking. And that's not saying anything about your performance expectations, since Racket's reader/expander probably won't be able to compete with a native compiler.

On 6/22/21 10:50 AM, D. Ben Knoble wrote:

No idea if this is what you're looking for, but I have a feeling it wouldn't be terribly difficult to design a #lang where modules were programs that, when run, output C# code (kind of like how scribble & pollen can output HTML). Then you could have a language (w/ or w/o) macros that gets run down to C# and let the C# compiler and project toolchain take care of the rest? Essentially it's only a syntax—the semantics is "turn it into this C# code." --

You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/a70bff98-e143-4c85-bcc9-2d919927764dn%40googlegroups.com.

--
~slg