Generics in Typed Racket?

[Alexis King]

So as it turns out, I have found myself sorely wanting generic interface support in Typed Racket. I understand that the class/object system seems to be the usual method of implementing interface-like polymorphism in Racket, but I actually much prefer the style of polymorphism that generics have to offer.

I am looking into how difficult the task of implementing generics would be in Typed Racket. As a preliminary step, I’ve reimplemented the parsing of define-generics to allow for type annotations in prims.rkt, but of course, that’s the fun part, which doesn’t take very much work. :P

Supporting the full set of features generics have to offer is a fairly daunting proposition, so obviously I’d want to work on getting a useful subset of the features instead. As far as I can tell, this can be subdivided into a set of smaller goals.

1. The simplest implementation would be one that would only work within typed code, would only work on structs that explicitly implement the generic interface, and would not support #:defaults of any kind.
   
   
1. First, this obviously requires introducing a “generic” type that would be defined by a new typed define-generics special form. This seems relatively straightforward—it should just declare a new type and a set of functions that use that type.
   
   
2. Also, the struct special form needs to be modified to support #:methods. The internal structure type would need to somehow be extended to include information about what interfaces it implements.
   
   Ideally, I’d prefer that generic types simply be disparate types, and structs that implement these types would become subtypes of the generic types. I’m not familiar enough with the type system to understand how feasible that would be.
   
   
3. Generics absolutely need to be polymorphic. I think an implementation of generics without parametric polymorphism would be a stunted one at best.
   
   
2. It would be cool to add support for #:defaults on all types that can be converted to flat contracts/predicates. Rather than supplying a predicate, one would supply a type, and occurrence typing would make using these pretty wonderfully simple. This isn’t something I’ve considered at all, beyond the basic concept of how I’d like it to work.
   
   
3. On the topic of interacting with untyped code, it would be nice to have a #:generics form in require/typed and an extension to #:struct to allow those to be used. I think all the machinery exists in terms of contracts, it would just need to be implemented.
   
   I actually don’t care about this all that much because I don’t find the use of generics to be very prevalent throughout existing Racket code. Obviously, it would need to be implemented eventually, but I would find immediate uses for generic support that would only function within typed code. In fact, wanting to use generics in a personal project of mine was what prompted me to look into this.

What I’m interested in finding out are some answers to the following questions:

• For those familiar with Typed Racket’s internals and implementation, how much of an undertaking does this appear to be? Would this be completely out of my grasp, or would it even be worth my time to look into?
  
  
• Similarly, if I began working on this, would anyone be willing to at least give me some pointers as I work through attempting to implement things? I’m still rather unfamiliar with the code base as a whole, but I am interested in putting in the effort to learn—I would just need to be able to ask questions… probably a lot of questions.
  
  
• For anyone at all, even those who never use Typed Racket, how much would you care about generic interface support in TR? A lot of things in Racket seem to theoretically support generic interfaces, but I don’t seem them used very much. Does anyone have any personal experience using them, or are they something of an unpopular feature in general?

I apologize for the wall of text. As a worst-case scenario, feel free to let me know that this is a project that’s probably too big for me to undertake at the moment, or that people are generally busy with other things. (I’m not being sarcastic, that’s a valid concern—sometimes that’s not clear in text-based communication.)

As a final note, I have a silly little branch in my fork of typed racket with the tiniest start of an implementation here. If I start working on this, that’s probably where the code will be.

https://github.com/lexi-lambda/typed-racket/tree/typed-generics

Thanks for any and all feedback—I’m definitely interested in helping to bring generics to TR, but I also can’t really escape the feeling that I’m in over my head on this one.

Alexis

[Marc Burns]

I'm currently porting a medium-size code base (~10,000 loc) that makes heavy use of Racket's OOP features to Typed Racket. I think I would have a number of uses for typed generics. Alas, I am probably less experienced than you with TR and can't offer much time toward this endeavor.

Best of luck and happy hacking!

--
You received this message because you are subscribed to the Google Groups "Racket Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+...@googlegroups.com.
To post to this group, send email to racke...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/347840BA-1D00-4FD9-8CA1-F4194AB963D6%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Vincent St-Amour]

At Sat, 7 Mar 2015 21:32:10 -0800,

Alexis King wrote:
>
> So as it turns out, I have found myself sorely wanting generic
> interface support in Typed Racket. I understand that the class/object
> system seems to be the usual method of implementing interface-like
> polymorphism in Racket, but I actually much prefer the style of
> polymorphism that generics have to offer.

FWIW, so do I. IMO, the transition from functions+structs style to
structs+generics style is smoother than to methods+objects.

It would be nice to also have a smooth structs+generics to
methods+objects transition, but I don't know how that would work yet.

> Supporting the full set of features generics have to offer is a fairly
> daunting proposition, so obviously I’d want to work on getting a
> useful subset of the features instead. As far as I can tell, this can
> be subdivided into a set of smaller goals.
>
> The simplest implementation would be one that would only work within
> typed code, would only work on structs that explicitly implement the
> generic interface, and would not support #:defaults of any kind.

I think it may be easier to start with the "`require/typed` untyped
interfaces" route. That way you avoid having to deal with typechecking
`define-generics` forms for now.

I think that may also get you a good portion of the use cases. It would
be possible to implement and use existing generics (e.g., `gen:set`)
from TR, and new generics for use in typed code could simply be defnited
in separate untyped modules and imported.

I haven't thought much about the type system aspects of generics + TR,
though, so it may be that the above plan doesn't actually simplify
things much. Just my 2c.

> I actually don’t care about this all that much because I don’t find
> the use of generics to be very prevalent throughout existing Racket
> code. Obviously, it would need to be implemented eventually, but I
> would find immediate uses for generic support that would only function
> within typed code. In fact, wanting to use generics in a personal
> project of mine was what prompted me to look into this.

I think the reason generics are not used pervasively is that they're
a relatively recent addition, and that a lot of the "obvious" use cases
would require retrofitting the standard library, which hasn't been done
yet. (I hope to get to work on that this summer, but I need to finish my
PhD first ;) )

> What I’m interested in finding out are some answers to the following questions:
>
> For those familiar with Typed Racket’s internals and implementation,
> how much of an undertaking does this appear to be? Would this be
> completely out of my grasp, or would it even be worth my time to look
> into?

I'd say: go for it! :)

I recommend you design the type system aspects first, then work on the
implementation. It's easier to iterate on the design that way, and
conceptual bugs should be apparent earlier in the process.

I won't lie, this is probably not going to be easy work, but it would
definitely be a good addition to TR, not to mention a major learning
experience for you. :)

If you need pointers/advice, feel free to ask Sam/Asumu/Eric/Andrew/myself.
From that group, Sam and Asumu are probably the ones most familiar with
the relevant type systems literature, and can probably point you to
papers with potential starting points.

Vincent

[Alexis King]

FWIW, so do I. IMO, the transition from functions+structs style to
structs+generics style is smoother than to methods+objects.

It would be nice to also have a smooth structs+generics to
methods+objects transition, but I don't know how that would work yet.

I’m glad to hear you agree. I personally find OO paradigms reasonable when performing side-effectful programming, but attempting to maintain purity while using OO is a nightmare. I’ve almost considered writing a wrapper around racket/gui using generics instead of classes just to see what that would be like.

I think it may be easier to start with the "`require/typed` untyped
interfaces" route. That way you avoid having to deal with typechecking
`define-generics` forms for now.

This is a good point. I think I may attempt to do just that.

I think the reason generics are not used pervasively is that they're
a relatively recent addition, and that a lot of the "obvious" use cases
would require retrofitting the standard library, which hasn't been done
yet. (I hope to get to work on that this summer, but I need to finish my
PhD first ;) )

Yeah, this was certainly my impression as well. I’d love to see generic collections in #lang racket2. :)

Anyway, thanks for the advice and comments! I’m not sure how quickly I’ll go about doing this, but it’s definitely something I’d like to work on, so I’d hope to make at least some progress within a semi-reasonable amount of time.

Plus I end up wanting it so often that I’ll probably be motivated to get it working as soon as possible. :P

[Matthias Felleisen]

On Mar 9, 2015, at 12:13 PM, Vincent St-Amour <stam...@ccs.neu.edu> wrote:

> I'd say: go for it! :)
>
> I recommend you design the type system aspects first, then work on the
> implementation. It's easier to iterate on the design that way, and
> conceptual bugs should be apparent earlier in the process.
>
> I won't lie, this is probably not going to be easy work, but it would
> definitely be a good addition to TR, not to mention a major learning
> experience for you. :)
>
> If you need pointers/advice, feel free to ask Sam/Asumu/Eric/Andrew/myself.
> From that group, Sam and Asumu are probably the ones most familiar with
> the relevant type systems literature, and can probably point you to
> papers with potential starting points.

Alexis, I am usually all in favor of encouraging contributions. The
more, the merrier. But this time around, I'd like to spell out what
such a project implies realistically before you go on an incredibly
difficult expedition.

1. I consider this project research, not just advanced development.

2. I tell all my PhD students

Research is when it can fail.

A failure might be a serious investment here.

3. Typed Racket has a design plan and philosophy. I think you're
basically familiar with the ideas -- your email touches on many
of these.

Here is how we proceeded with adding types to classes, and I think
our experience shows that this is a good routine:

-- collect examples of uses [hard, because as Vincent says,
generics are new]
-- explore literature [the very original papers on Haskell's
generics might be a good fit here; I am having Ben G.
read up on this because many are interested in this]
-- pick a few examples from step 1 as 'formative tests'

-- design syntax of types, meaning
-- design type system and make sure your examples go through
[a Redex model worked really well, easy prototyping
and can run existing Racket examples usually]
-- repeat these steps until stable

-- argue that the type system is sound (all of its predictions
are true)

-- design type to contract compiler
-- argue the combination is sound
-- repeat these steps until stable

== You may have to backtrack all the way up to syntax/meaning
to fix problems here

-- evaluate expressiveness
-- evaluate performance

== You may have to backtrack again all the way up to syntax/meaning
to fix problems here

Some of these steps call for novel ways of doing things.
Some just call for doing old things right. I am sure you
can call on help for some of the implementation and/or
work-intensive parts. But if people didn't follow along
with your development, they need ways to find out what
your design decisions are.

You will need to keep writing little essays on these steps
so that people can join you.

We have been through this twice now for significant projects (classes,
units). We have done it smaller things. If I considered generics small,
I wouldn't write this message.

Adding type isn't just an implementation project. If you're still
up for it, make a plan, Add it to your project pages. Develop a
work routine. Develop a writing routine. Ask for help. A lot. Be
prepared to spend a serious amount of time.

-- Matthias

[Alexis King]

Thank you for your warnings. I certainly didn’t anticipate it to be straightforward, but yes, it’s also probable I’m not up to the task. I definitely haven’t tried very much just yet, and I’m still undecided if I want to pursue this at all (at least for the time being).

I do want to take a moment to discuss something that I was talking with Eric (and briefly with Andrew) about on IRC a short while ago because it’s something that I think puts Typed Racket in an interesting position.

I encountered Typed Racket as an end user—someone who was just interested in using it for ordinary programming—and I came upon it at a time in which it’s honestly a very practical drop-in replacement for a large portion of Racket. Especially with the newly added support for the class system, it’s remarkably capable language, and I find it to be a superior experience to using untyped Racket in most ways.

Of course, what’s curious about Typed Racket is its approach to taking an existing untyped language and adding static typing to it without altering any idioms whatsoever of the underlying language. This is an admirable research project as well as a highly practical goal since it means converting to Typed Racket is extremely straightforward. I’ve found occurrence typing absolutely stunning at times in the pure spectrum of situations it can accurately type. (Especially with the new DrRacket tooltips that I think Asumu added, which show how occurrence typing propagates, and it’s awesome.)

The downside, of course, is that TR’s abstraction is leaky at times—I have wrangled with the type system more than I would have liked, and especially when typed code interacts with untyped code, it can be rough around the edges. Despite this, there are still soundness holes in weird edge cases because, well, enforcing types everywhere with the level of fined-grained control that TR’s type system provides is really hard (especially when things can be mutable).

So on the one hand, I totally understand Typed Racket as a research project, and it’s a fascinating and highly successful one at that. I am deeply grateful for all the work and ingenuity that has been poured into it. On the other hand, I also view TR has a practical tool I want to use in programming, and sometimes it’s very easy to run into its shortcomings when pushing it to its limits in real-world code. In some cases, Typed Racket has already sacrificed soundness for practicality (whether originally intentional or not), but honestly I don’t think that’s much of a problem since people will never stumble upon it unless they are explicitly trying to break the type system.

Anyway, I guess what I’m really saying is that I feel like maintaining all untyped Racket idioms and being able to interact with untyped code makes it almost impossible to maintain perfect soundness everywhere.

So whatever, that’s my opinion. (I’d be possibly interested in writing a different, non-Racket-like typed language on top of Racket, but that is an entirely different conversation for another time.) What does any of this have to do with generics?

Some of it doesn’t, it was really just me wanting to have a tangentially-related discussion. That said, I’d also argue the following:

• Typed Racket’s implementation of generics is already going to be highly restricted based on Racket’s implementation of generics since all dispatch has to be purely dynamic. It couldn’t use static dispatch, anyway, due to subtyping.
  
  
• Building upon that, I’m not sure it’s even possible to design an adequate generics system with no soundness problems given Racket’s capability for struct subtyping. (It probably could be possible by introducing some additional contract mechanisms, possibly to the core, but that’s far out of my scope.) As far as I can tell, a large number of the current issues with soundness already revolve around struct subtyping—Eric is obviously much more aware of that than I am, though.

Fundamentally, given the constraints placed on the system, it doesn’t feel like there are all that many possibilities for introducing Racket’s generics to TR. Since it’s something I’d find incredibly helpful in real code, my first instinct is to just bolt it on.

Obviously, “just bolt it on” isn’t satisfactory for something of this significance, but even if I tried it and subsequently failed horribly and ended up with a half-functional mess that could be easily broken, I’m still tempted to try anyway because I think even a broken implementation would have real utility, and it could help to serve as an illustration for what doesn’t work and how it could be fixed.

Basically, I’m considering forking TR and adding a hacky generics implementation without much thought so people can break it. Feel free to try to talk me out of it (I haven’t even decided if I want to try yet or not), but I think that’s currently my frame of mind.

Alexis

[Matthias Felleisen]

On Mar 12, 2015, at 11:50 PM, Alexis King <lexi....@gmail.com> wrote:

> Thank you for your warnings. I certainly didn’t anticipate it to be straightforward, but yes, it’s also probable I’m not up to the task. I definitely haven’t tried very much just yet, and I’m still undecided if I want to pursue this at all (at least for the time being).

Sorry, this warning wasn't about 'you' I would have warned everyone else in the same way :-) or perhaps :-( What I wanted to say in short was:

-- "you" can build and extend any given system
-- "you" may end up spending a ton of time on it
-- "you" may discover in the end that it feels wrong, it is wrong, it is incomplete and must remain so.

As someone who always has his advisor hat on and as someone who has seen other young people fail -- and hate this kind of failure to the point of rejecting all future engagement with research-y things -- I had to warn you. Now that you have been warned, your rights have been read to you, and you made your one phone call -- go for it. Just don't ever say, you hadn't been warned. Fork is good.


A lot of what you say below is spot-on. You have picked up and absorbed the ideas behind Typed Racket, incremental types, and type-system design. But here is the neat thing about academic research:

we can set a high bar, we can set goals that look nearly unreachable, and we can strive to get there w/o compromise.

In the process, we will fail, we will learn, we will have fun. We will weep, cry, scream for disappointment and for joy. But, unlike industrial types or faux academic types, we don't ever have to say "let's compromise right now for good because we want to be relevant immediately." We can say that and we can equally well move toward our unreachable goal.

Society has given us this space. It expects that most of us will fail. It expects that others learn from our failures. And in return, we have a moral obligation to search.

Think of Typed Racket in this spirit. Think of the short-cuts and compromises you encounter as human failings of certain participants in this endeavor. And think of me as the guy who goes for the big goal and whose job it is to remind others to go for that.

-- Matthias

[Sam Tobin-Hochstadt]

On Thu, Mar 12, 2015 at 11:50 PM, Alexis King <lexi....@gmail.com> wrote:
> Thank you for your warnings. I certainly didn’t anticipate it to be
> straightforward, but yes, it’s also probable I’m not up to the task. I
> definitely haven’t tried very much just yet, and I’m still undecided if I
> want to pursue this at all (at least for the time being).
>

> I do want to take a moment to discuss something that I was talking with Eric
> (and briefly with Andrew) about on IRC a short while ago because it’s
> something that I think puts Typed Racket in an interesting position.
>
> I encountered Typed Racket as an end user—someone who was just interested in
> using it for ordinary programming—and I came upon it at a time in which it’s
> honestly a very practical drop-in replacement for a large portion of Racket.
> Especially with the newly added support for the class system, it’s
> remarkably capable language, and I find it to be a superior experience to
> using untyped Racket in most ways.

Aw, thanks!

> The downside, of course, is that TR’s abstraction is leaky at times—I have
> wrangled with the type system more than I would have liked, and especially
> when typed code interacts with untyped code, it can be rough around the
> edges. Despite this, there are still soundness holes in weird edge cases
> because, well, enforcing types everywhere with the level of fined-grained
> control that TR’s type system provides is really hard (especially when
> things can be mutable).

I think this runs together two different issues which it's important
to keep separate.

First, Typed Racket has a complex and powerful type system because
that's what's needed to handle idiomatic Racket code. Furthermore,
we're continuing to make it more complicated to handle things like
classes, units, and hopefully generics as you propose. To the best of
my knowledge, the statically-typed portion of this type system is
sound; places where it isn't are simple bugs. This has required a
bunch of new research to get right, of course.

Second, Typed Racket is embedded in Racket, and must defend itself
against against accidental or malicious programs. This includes both
simple interaction with untyped code, as well as reflection and other
complex features. Unfortunately, this is also easy to get wrong, and
we've gotten it wrong plenty of times. There are indeed some holes
that continue to exist, and unfortunately closing these holes in the
most conservative way would fundamentally break some existing
programs, which we'd prefer not to do. However, we're working on this,
and I look forward to the day that Typed Racket's soundness is as
reliable as plain Racket's memory safety.

> So on the one hand, I totally understand Typed Racket as a research project,
> and it’s a fascinating and highly successful one at that. I am deeply
> grateful for all the work and ingenuity that has been poured into it. On the
> other hand, I also view TR has a practical tool I want to use in
> programming, and sometimes it’s very easy to run into its shortcomings when
> pushing it to its limits in real-world code. In some cases, Typed Racket has
> already sacrificed soundness for practicality (whether originally
> intentional or not), but honestly I don’t think that’s much of a problem
> since people will never stumble upon it unless they are explicitly trying to
> break the type system.

I disagree with both of these claims. First, unsoundness is a real
problem, and one that people stumble upon even when they aren't
trying. We need only to look at the long history of C vulnerabilities
to see this. Second, Typed Racket isn't sacrificing soundness for
practicality. Sometimes, we have bugs, and we have not fixed them all.
We're also not always willing to fix a bug if we don't have a fix that
works well for existing users -- if they've relied on something
working, we shouldn't make their whole program break permanently.

> Anyway, I guess what I’m really saying is that I feel like maintaining all
> untyped Racket idioms and being able to interact with untyped code makes it
> almost impossible to maintain perfect soundness everywhere.

I think maintaining untyped idioms doesn't require compromises --
except on amount work and research we need to do. I encourage you to
start in on that work, and I'm happy to help. But an important part of
that is maintaining the philsophy of Typed Racket, including soundness
and faithfulness to existing Racket programs.

> Typed Racket’s implementation of generics is already going to be highly
> restricted based on Racket’s implementation of generics since all dispatch
> has to be purely dynamic. It couldn’t use static dispatch, anyway, due to
> subtyping.

This is not, I think, correct about subtyping. For example, Scala does
static determination of implicits, despite the presence of subtyping.
But if you mean that Typed Racket's generics won't be the same as
Haskell's, since Racket's generics aren't either, then yes, that's
correct. But you can still do many impressive things with them -- for
example, Tony's monad implementation here:
http://www.eighty-twenty.org/2015/01/25/monads-in-dynamically-typed-languages/

> Building upon that, I’m not sure it’s even possible to design an adequate
> generics system with no soundness problems given Racket’s capability for
> struct subtyping. (It probably could be possible by introducing some
> additional contract mechanisms, possibly to the core, but that’s far out of
> my scope.) As far as I can tell, a large number of the current issues with
> soundness already revolve around struct subtyping—Eric is obviously much
> more aware of that than I am, though.

Again, I don't think this is true, and it's confusing the two issues
that I distinguished earlier. If we don't yet know how to generate
contracts for generic function types, we can simply not implement
that, but that doesn't require soundness holes.

> Fundamentally, given the constraints placed on the system, it doesn’t feel
> like there are all that many possibilities for introducing Racket’s generics
> to TR. Since it’s something I’d find incredibly helpful in real code, my
> first instinct is to just bolt it on.
>
> Obviously, “just bolt it on” isn’t satisfactory for something of this
> significance, but even if I tried it and subsequently failed horribly and
> ended up with a half-functional mess that could be easily broken, I’m still
> tempted to try anyway because I think even a broken implementation would
> have real utility, and it could help to serve as an illustration for what
> doesn’t work and how it could be fixed.
>
> Basically, I’m considering forking TR and adding a hacky generics
> implementation without much thought so people can break it. Feel free to try
> to talk me out of it (I haven’t even decided if I want to try yet or not),
> but I think that’s currently my frame of mind.

As Matthias said, research can always fail. If you make an effort in
one direction and show that it doesn't work, or that more is required
to make it work, that would be highly valuable.

But I don't think that approaching this as "forking TR" is a good
idea. TR has managed to successfully handle a wide variety of tricky
Racket features, and I'm sure we can do generics too.

A separate issue, which you mention in passing, is whether Typed
Racket is the be-all and end-all of types in the Racket ecosystem.
Currently it's the most popular, but I think there's room for other
systems as well. If you, or anyone else, want to develop a
Haskell-like or ML-like or Scala-like system in Racket, that sounds
like a great idea to me. You wouldn't be constrainted by existing
Racket programs, and who knows what interesting things would develop.

Sam

[Alexis King]

Thank you both for your replies on this. Matthias, I think your description is spot-on, and I absolutely agree with that attitude. I think there is something of an internal struggle within me that really wants Racket to be a practical general-purpose programming language that’s applicable now, but I also massively appreciate the goal to find clean, sound ways to solve existing problems, even if those solutions aren’t immediately obvious.

I think this runs together two different issues which it's important
to keep separate.

Yes, I do understand the amount of complexity arising from how dynamic Racket can be at times. I guess what I find intriguing about that is how much of Typed Racket’s implementation is dependent on having suitable hooks in the rest of Racket in which TR can insert checks (e.g. contracts), and those hooks cannot be implemented in Typed Racket alone. I actually view this as a positive thing, since it extends the capability of the core language in good ways. It just means that developing Typed Racket is unquestionably tied to developing Racket.

But I don't think that approaching this as "forking TR" is a good
idea. TR has managed to successfully handle a wide variety of tricky
Racket features, and I'm sure we can do generics too.

I want to make it clear that I never intended making any sort of permanent fork of the language. I’d view that as extremely stupid, especially given the relatively small, already-fragmented userbase of Racket. I was just considering the idea of spinning off an experimental fork to test out some ideas, not intending to merge it back into TR at any point, but also not intending to keep it around once it had served its purpose.

A separate issue, which you mention in passing, is whether Typed
Racket is the be-all and end-all of types in the Racket ecosystem.
Currently it's the most popular, but I think there's room for other
systems as well. If you, or anyone else, want to develop a
Haskell-like or ML-like or Scala-like system in Racket, that sounds
like a great idea to me. You wouldn't be constrainted by existing
Racket programs, and who knows what interesting things would develop.

I’d certainly be interested in building a language in Racket with Haskell-like semantics but with the syntactic power of Racket. I don’t think I’d go for the full power of Haskell, but maybe something a little softer to still permit Racket interoperability while forgoing the need to support existing Racket idioms.

But that, of course, is a project for another time.

Alexis

[Matthias Felleisen]

On Mar 15, 2015, at 12:41 PM, Alexis King wrote:

But I don't think that approaching this as "forking TR" is a good
idea. TR has managed to successfully handle a wide variety of tricky
Racket features, and I'm sure we can do generics too.

I want to make it clear that I never intended making any sort of permanent fork of the language. I’d view that as extremely stupid, especially given the relatively small, already-fragmented userbase of Racket. I was just considering the idea of spinning off an experimental fork to test out some ideas, not intending to merge it back into TR at any point, but also not intending to keep it around once it had served its purpose.

I understood that, and again, I encourage you to play and be prepared to fail and to be frustrated. [I consider this (if it doesn't happen too often) a part of the joy of doing what I do.]

I’d certainly be interested in building a language in Racket with Haskell-like semantics but with the syntactic power of Racket. I don’t think I’d go for the full power of Haskell, but maybe something a little softer to still permit Racket interoperability while forgoing the need to support existing Racket idioms.

There is no power in syntax :-]