I just thought you guys may want to talk about this either here or on Haskell’s Discourse: What Would It Take To Make "Elm Embedded In Haskell" Available In GHC? - Haskell Community)
I’ll copy my post here from there:
Haskell lacks what Elm has and Elm lacks what Haskell has. Both are arguably “best in class”, amazing technologies: Elm for the frontend and Haskell for the backend.
If they were a little more unified, Haskell and Elm together could offer a remarkably strong value proposition. If some differences were alleviated they could be a uniquely powerful combination.
Haskell and Elm are just different enough to derail a powerful synergy that could strongly motivate a much wider adoption of both technologies/ecosystems. Haskell used with Elm is an appealing combination but doesn’t satisfy those looking for a more uniform front-end and back-end language solution. Javascript and Rescript etc already offer this with perfect uniformity. If the proposed adaptation of GHC were implemented then the newly “Elm-retrofitted-Haskell” together with Elm would be surprisingly advanced compared to alternative “full-stack” solutions. It’s a shame that Haskell and Elm are currently just different enough to be missing out on what could be an amazing pairing.
Given that the Elm Language is, roughly speaking, a subset of Haskell with some differences, could GHC successfully/realistically be modified to provide an optional mode where the Elm language becomes embedded within Haskell? For features that overlap in Haskell and Elm, the Elm syntax/semantics would be adopted (other than strict evaluation). All the unique features of GHC Haskell that have no equivalent in Elm would continue to be available for use alongside the new Elm syntax.
To make this change, implementing Elm-style records seems to be the biggest challenge. Fortunately, Elm’s records are, from what I’ve seen, generally hailed as an improvement over Haskell’s records. Appearing later in history, presumably the design of Elm records benefited from newer research and greater historical perspective over what was available when people were engineering Haskell records. I’m not sure how much Elm’s choice of record semantics is an outgrowth of the underlying reality of Javascript or if Elm records are just generally/universally so great so that even the Haskell community would actually adopt Elm’s record’s for itself if it was as simple as just starting over.
Beyond records, Elm has the following syntactic differences:
- Elm has multi-line strings: “”"…"""
- Elm has a different import syntax
- Elm’s type signatures use “:” instead of “::”, and likewise cons is “::” instead of “:”
- Elm uses “List” instead of “[]” in type signatures
- Haskell’s brace brackets “{}” could collide with Elm’s record literals
Elm is pretty simple, are there other overlapping but differing features?
**
Generally speaking, how realistic of an undertaking would this be? How much would your ballpark estimate be to pay someone to get it done? How realistic is it to just pay someone to make this kind of a change, considering the specialized nature of the work? How maintainable would this be? What would it take to adapt and maintain tools like the Haskell language server with these new differences?
If an Elm backend did get developed to maturity, it would likely be based on Node, but Haskell would be a superior host in terms of technology while also being much more culturally/spiritually aligned with Elm.
Haskell on the front-end seems that it will never quite rival the sharp, custom-tailored tool that is Elm. As it is, it seems Haskell is likely to narrowly miss out on attracting a much larger community of web developers. I say “narrowly miss out” because Elm, the near perfect catalyst is so close at hand.
Arguably we could also take a different approach, and make a version of Elm using a similar but more accurate subset of Haskell…but this seems like a poor direction as it would be trying to produce and popularize a slightly weaker (less tailored) version of something that already exists in Elm. Elm has already established itself. Elm has the advantage and momentum that a new, similar project is unlikely to rival.
The benefits would, I think, easily outweigh the cost of somewhat fracturing the Haskell ecosystem (with the “new”, alternative, Elm-based syntax). For experienced Haskell users this would hopefully just be a trivial annoyance if it comes up. For learners coming from Elm, the increased uniformity could make the difference between enthusiasm about learning “Elm-adapted-Haskell”, which would then be perceived as building on their existing Elm knowledge and experience versus them experiencing apprehension at being forever plagued by inconsistencies between Haskell and Elm. The new language combination would need a new name (I like the name “q”) and learning resources would need to be adapted or newly created. But on the positive side, courses could be created that teach Elm in the first year, and “q” (Haskell with Elm embedded) in the second year, and there would be continuity and consistency while moving between the languages. Elm would become, even more than it is already, a solution to the complexity challenge of learning Haskell.
We could make the new Elm-Haskell amalgamation also be a focal point for a culture which is heavily focused on basics and practical fundamentals.
…and then this is me replying to the first response I got:
What I mean to propose and ask about is whether it would be realistic to do all this as something like a GHC “extension” rather than a hard fork. If Elm records are superior to Haskell’s then the biggest part of this proposed alteration of Haskell would be an improvement, and the rest are a few syntactic changes that enhance uniformity with the rest of Elm.
I agree that the biggest challenge in learning Haskell when coming from Elm is not the syntax, but little syntax paper cuts would be wonderful to remove, and they do make a difference. It’s like when I get an actual paper cut, I’m very unhappy about the paper cut even though it’s not the biggest challenge I face, and yes you could rightly say I was overly focused on the paper cut. Even though “q” would be a highbred of Haskell and Elm it would probably attract libraries which are influenced by or harmonious to Elm’s libraries. For example, the way Elm doesn’t use partial functions like “head” in Haskell for example.
So in a nutshell, the suggestion is to improve on Haskell (records) and at the same time join/unite two powerhouse technologies/ecosystems without a hard fork.