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 -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/E9649E82-01FF-4CF2-BB77-8F78AC0A3DD4%40gmail.com. For more options, visit https://groups.google.com/d/optout.
