4 ms·

Haskell is poorly equipped for implementing compilers because writing compilers in Haskell requires tons of boilerplate, which is not needed in the languages th

by sklogic 11y ago

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.

coldtea 11y ago
>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"?
- sklogic 11y ago
  > 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 http://www.cri.ensmp.fr/classement/doc/A-381.pdf [2] https://github.com/eholk/harlan https://github.com/eholk/harlan
  - coldtea 11y ago
    >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.
    - sklogic 11y ago
      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.
      - coldtea 11y ago
        >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...

by sklogic 11y ago

coldtea 11y ago

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

sklogic 11y ago
> 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 http://www.cri.ensmp.fr/classement/doc/A-381.pdf [2] https://github.com/eholk/harlan https://github.com/eholk/harlan
- coldtea 11y ago
  >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.
  - sklogic 11y ago
    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.
    - coldtea 11y ago
      >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...