Hacker News Reader

So "Haskell is poorly equipped for implementing compilers" because it doesn't fit your bizarro requirements, including "efficient embedded Prolog and Datalog"...

Haskell is poorly equipped for implementing compilers because writing compilers in Haskell requires tons of boilerplate, which is not needed in the languages that are a much better fit for this task. Kinda obvious from a definition of what "poorly equipped" means.

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.

>Haskell is poorly equipped for implementing compilers because writing compilers in Haskell requires tons of boilerplate, which is not needed in the languages that are a much better fit for this task.

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"?

> are even more niche

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?

[1] http://www.cri.ensmp.fr/classement/doc/A-381.pdf

[2] https://github.com/eholk/harlan

>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.

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 features I am talking about are very platform-agnostic. The only requirement for implementing them is a compile-time metaprogramming, which is trivial to add to any language, including C.

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.

>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.

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...

I am glad you did not list anyone related to GCC and LLVM, because both rely on the static DSLs (and code generation) heavily.

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.

>They can all be great language designers, but their approach to compiler construction is needlessly overcomplicated.

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.

JIT is a totally different beast from a simple pipeline compiler. You should have known better. Anyway, you evidently do not know what you're talking about. Consider you trolling unless you can show your compiler code.

Out of curiosity, what language, if any, has those properties?

Any language that allows compile-time metaprogramming (and not as restricted as TH) should allow to implement all the components I want. One example of such a system is the Nanopass framework [1], used alongside with cKanren [2].

Another example is my own system [3].

[1] https://github.com/akeep/nanopass-framework http://www.cs.indiana.edu/~dyb/pubs/nano-jfp.pdf

[2] http://scheme2011.ucombinator.org/papers/Alvis2011.pdf

[3] https://github.com/combinatorylogic/mbase

@sklogic, I have been looking for something like MBase. Is there something like a beginner's tutorial anywhere?

There is a bit outdated tutorial in https://github.com/combinatorylogic/mbase/tree/master/misc/d...

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.

> 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.

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.

What are your parsing requirements?

Pretty basic: graceful error recovery, arbitrarily complex error reporting, arbitrary actions (potentially with some side effects). I.e., everything that is needed for the IDE integration and for the professional compiler frontends with usable, friendly error messages and recovery suggestions.

Try these:

https://hackage.haskell.org/package/trifecta

https://hackage.haskell.org/package/parsers

They are meant to be used together.

Could you please point at their error recovery functionality (I could not find it by a quick scan)? My gut feeling is that combinator-based parsing is not very well suited for this, but I may be missing something obvious.

This is the chief drawback of these two libraries: they are poorly documented (and are arguably not documented at all). In general, parsers is for parsing and trifecta is for reporting errors and diagnostics. Trifecta looks especially nice for giving context to error sites, but I haven't used it much yet (only for highlighting, really).

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!

Thanks! I'll take a look at these projects.

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.

`trifecta` is basically produces `clang`-style error messages (i.e. they have the pretty colors, underlined text spans, cursor pointers into the text, and really good error messages indicating the real problem and not some unrelated problem). That's why most people recommend `trifecta` when error reporting quality is paramount.

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.

Ok, I think I understand now how it works (played with Idris parser a bit). Sort of a simple trick, I'll borrow it for the lower tier combinator-based parsing layer.

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.