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.
On Monday, June 7, 2021 at 10:07:56 AM UTC-5 Stephen Foster wrote: > This is one of the main ways I use Racket -- but as a front-end for > JavaScript, not C#. > > On Sunday, June 6, 2021 at 9:47:38 PM UTC-7 Philip McGrath wrote: > >> 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 >> >> >> On Sun, Jun 6, 2021 at 11:35 PM Robert Calco <[email protected]> wrote: >> >>> Check out IronScheme <https://github.com/IronScheme/IronScheme>... it >>> may be just what you're looking for. >>> >>> - Bob >>> >>> On Sun, Jun 6, 2021 at 10:02 PM Ryan Kramer <[email protected]> >>> wrote: >>> >>>> 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? >>>> >>>> -- >>>> 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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/racket-users/cc7c1792-ba59-400f-856a-3bb02a6096fbn%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/racket-users/cc7c1792-ba59-400f-856a-3bb02a6096fbn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> >>> >>> -- >>> *Bob Calco* >>> >>> [email protected] >>> 813-997-3583 <(813)%20997-3583> (work mobile) >>> 813-523-3751 <(813)%20523-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* >>> >>> -- >>> 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 [email protected]. >>> >> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/racket-users/CAATHPo3MJDtgxrt3FKPTRvt-avaniq4LTwF6VH_SSe%3DvAV3V4A%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/racket-users/CAATHPo3MJDtgxrt3FKPTRvt-avaniq4LTwF6VH_SSe%3DvAV3V4A%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/b59796d9-262b-44a9-bc28-3011a178ef3cn%40googlegroups.com.
