And why do you call these basic requirements bizarre? For example, something like a region inference is just a few lines of Prolog vs. dozens or even hundreds of lines of code in Haskell.
And yet your "much better languages" are even more niche compared to Haskell, and no major programming language has been written in them.
So, it's basically "Haskell is poorly equipment compared to my impossible standards, as implemented by this hodge-podge of Scheme based tools that I alone ever used together for compiler implementation".
>And why do you call these basic requirements bizarre? For example, something like a region inference is just a few lines of Prolog vs. dozens or even hundreds of lines of code in Haskell.
Because no known programming language resorts to "a few lines of Prolog" to save a few tens of lines for "region inference"?
Exactly. Compilers construction is a very specific problem domain, which requires specially tailored DSLs, not a "general purpose" language. Haskell is a way too general purpose for this task.
> and no major programming language has been written in them.
C is even more unsuitable for this than Haskell, and yet most of the compilers are written in C. Technical superiority does not count at all in choosing an implementation platform.
> Because no known programming language resorts to "a few lines of Prolog" to save a few tens of lines for "region inference"?
JFYI, a prototype implementation of SSA for GCC was written in Prolog (see the Sebastian Pop works [1]). If embedding Prolog in C was technically feasible, it would have stayed this way. Also, to see how much Prolog rocks, check out Harlan [2]
In order to avoid unnecessary flame war: I give no crap to any popularity based arguments. Got any technical, well-grounded, rational arguments? Go on, I'd be delighted to comment. Otherwise I'm not interested. And, btw., you're clutching to just one out of four of my points against Haskell. Nothing to say about the other three?
Or maybe technical superiority is a more varied thing than what you consider (merely a language's features and "expression" capabilities), and includes tooling, portability, speed, direct access to hardware, existing codebase to work upon and lots of other parameters, for which C was king or very near the top for many decades...
>In order to avoid unnecessary flame war: I give no crap to any popularity based arguments.
And from my side: I don't give a crap for "technical arguments" that focus only on a very narrow area of technical benefits ignoring lots of others.
Even "familiarity of the team with a language" is a technical argument (in the sense that it speaks to the capability of a teams to practically use something).
I also don't think that "popularity" is just fluff. It might not be a 100% solid proof, but it does point to real, battle proven, results (as oposed to vapour-ware and hand-waving about superiority).
In the end, history and actual results are the only criteria. That's being pragmatic and empiricist -- as opposed to mere beliefs that don't pan out in practice.
The only explanation for not using this approach is a plain ignorance. Majority of people have no understanding of compilers at all. And yet they are writing compilers. In C or Haskell.
And, btw., teams that cannot learn a tiny DSL in an hour (or write this DSL in a week) should not be allowed to write compilers. It's kinda obvious.
That includes people like Lars Bak, Martin Odersky, Anders Hejlsberg, Simon Peyton Jones, etc? I wonder where the burden of proof should be placed in these kind of arrogant arguments -- as if "compile-time metaprogramming" is some magic bullet for compiler design...
As for the rest - yes, compiler construction is not their main research topic. They can all be great language designers, but their approach to compiler construction is needlessly overcomplicated.
A view of a compiler as a chain of stupidly trivial passes, ideally expressed as term rewriting, is not very common among the researchers, but so far it yields the best results.
Actually Lars Bark and team are not "language designers". Smalltalk (Strongtalk), Java (Hotspot), Javascript (V8), all have been designed as languages by other people.
They are world reknowed experts in compiler design.
Another example is my own system [3].
[1] https://github.com/akeep/nanopass-framework http://www.cs.indiana.edu/~dyb/pubs/nano-jfp.pdf
Also, CLike project was supposed to be a sort of a tutorial.
For a more thoroughly documented, production-ready language workbench you can also try Racket alongside with Nanopass framework.
Have you tried QuickCheck?
> 4) Parsing is not very important. But yet, it is necessary. The best Haskell got on offer is Parsec. Sorry, not good enough for my requirements.
I've not found much better than (atto-)Parsec, to the point where I miss it in other languages.
https://hackage.haskell.org/package/trifecta
https://hackage.haskell.org/package/parsers
They are meant to be used together.
By "error recovery," do you mean backtracking? If so, there are several ways of doing that, which can be found here:
https://hackage.haskell.org/package/parsers-0.12.2.1/docs/Te...
See the 'choice', 'option', and 'try' combinators, and also the '<|>' operator in Control.Applicative.
If you need more than that, you can extend parsers' monadic parsing to roll your own error recovery.
Currently, the best way to understand how parsers and trifecta work is to look at projects that use them. I will give you some links to the ones I've used and found helpful, if a bit more complicated than the parsers I am currently writing:
https://github.com/ekmett/ermine/tree/master/src/Ermine
https://github.com/idris-lang/Idris-dev/tree/master/src/Idri...
And here is a relevant Reddit thread, which includes a link to Edward Kmett's slide deck which motivates trifecta/parsers and gives a high-level view of how they work:
https://www.reddit.com/r/haskell/comments/2uc6kp/are_there_a...
I hope this helps!
By recovery I mean something like "f(x,y,z;" triggering an error message "did you miss ')' here?", with parser recovering and proceeding further, in a hope to report more errors in a single run - see how Clang handles this, with a handcrafted recursive descent parser.
Backtracking does not help here, it must be done with custom heuristics at each node. I am doing this kind of things declaratively on top of an elaborate PEG-based generator (using an idea of signals attached to both successful and failed branches, and then choosing which signals to execute based on the exact points of failure), but would be very interested to see a lightweight combinator-based solution.
The author of the `trifecta` library is extremely knowledgeable about parsing/backtracking/recovery/error-reporting and has put a lot of thought into how to improve error message relevance as much as possible.
I was even more interested in handcrafted, custom error messages rather than constructed. Still cannot figure out how to stuff custom recovery heuristics into a combinator-based code.
Uhm, no, thank you, but no. Haskell is poorly equipped for implementing compilers, because of its lack of unrestricted compile-time metaprogramming.
I'm spoiled. This is what I want from a language for implementing compilers:
1) Cheap, boilerplate-free definition for chains of slightly different ASTs and IRs. Haskell and ML are notoriously weak in this area (see the "Expression Problem" thing)
2) Boilerplate-free generation of various (potentially complex) visitors for these ASTs and IRs. For Haskell, Scrap Your Boilerplate library is the closest thing to what I want, but it is still far too clumsy.
3) I need efficient embedded Prolog and Datalog (yes, both, the latter allows some cool optimisations not possible for the former). Not feasible without compile-time metaprogramming. Both are important for simplifying compiler construction.
4) Parsing is not very important. But yet, it is necessary. The best Haskell got on offer is Parsec. Sorry, not good enough for my requirements.