What Does Haskell Have to Do with C++? | Hacker News Reader

What Does Haskell Have to Do with C++?

bartoszmilewski.wordpress.com

51 pointsVeXocide23 comments

I see (and it is certainly highly subjective) one large similarity between Haskell and C++: Haskell and C++ code looks similar to me aesthetically, as in indentation patterns being similar and so on, it's certainly weird :)

Also it is interesting to note, that both Haskell and C++ world is full of discussions about how to do something remarkably complex to get nice syntax for something. You don't see that in lisp world, where such problems are simply solved by macros and nobody goes into great lengths to (ab)use some random language feature to get nice syntax for his library.

This happens in a ton of languages, e.g. Ruby (method call syntax and blocks), Scala (idem), C# (LINQ syntax), etc.

Template Haskell (or a more general pre-processor) can eliminate most of these discussions, too.

Nice syntax? C++ gurus have ascended above that a long time ago.

Nice compiler error messages are the real thing now.

Seriously: I feel the need to express something in a concise and somewhat beautiful way to be a large part of C++ culture and partly a reason for so many people shying away from less expressive languages. Some of the Boost libraries are even centered around the whole idea and required a lot of effort (see Boost::assign).

The nice thing about single-paradigm languages like Haskell is that they have very simple syntax (think of Lisp that does everything with just a bunch of parentheses).

This statement suggests the author has limited exposure to Common Lisp, which supports the widest variety of programming paradigms in one language that I can think of. Simplicity of syntax seems to be mostly orthogonal to allowing the use of many paradigms, though it's probably hard to have a very complex syntax with a semantically simple language.

In my view, these issues are not orthogonal, but related in exactly opposite way that article author allures to. At least when you view Common Lisp's syntax as simple (CL has same feature as Perl and TeX - only unambiguous and reliable way to parse it is to actually run it).

A quick Google doesn't turn up any pages stating that parsing Perl and CL is undecidable. Can you provide a reference?

I don't know about CL, but it is commonly believed that Perl cannot be parsed by anything except Perl. I'm not sure about the nuances between "undecidable" and "cannot be parsed without execution", but this page seems relevant:

Perl Cannot Be Parsed: A Formal Proof

http://www.perlmonks.org/?node_id=663393

Oops! I meant that Google didn't turn up anything for TeX, not Perl. The Perl stuff is indeed well known.

There is large difference between "undecidable" and "cannot be parsed without execution". It has to do with the fact that in each of these three cases the syntax can be modified by running code, and that execution is interleaved with parsing. In CL you can essentially add arbitrary right sides to few production rules of it's grammar, and also meaning of many tokens (symbols, numbers and differentiating between symbols and numbers) is dependent on runtime state of implementation which can be modified by code being parsed. In TeX you can partially alter rules of tokenization (by redefining character categories).

And in the TeX case it also depends on what you expect as output of parsing, if you want some meaningful AST, it is even more complex (and probably impossible). Because even if you would remove the ability to redefine character categories, you would still be able to only get stream of tokens without clear semantic meaning.

But whole this discussion is mostly theoretical, because for reasonable inputs (like LaTeX), parser can effectively guess. Also, in CL cases many of these problems are solved by various conventions (like having most of relevant state consistent for whole file and specified in comment that is readable by said tools).

Common Lisp, which supports the widest variety of programming paradigms in one language that I can think of

Allow me to introduce you to Mozart/Oz and AliceML. Seriously, those two twin languages are the most epic out there.

You would have to hack CL extensively, and bundle various libraries to make it on par with Oz or Alice. Maybe CL + Screamer + FSet + Heresy + pcall + cl-store would be a pale, distant imitation.

For the last 50 years, PL research has been done with minimal kernel languages, implementing few features. Don't know what mental mutation caused the Oz team to go the opposite way and implement "everything imaginable" in a tiny language, but I like it. The core of Oz is no larger than Scheme, btw.

Oz is an interesting language. I only learned it because I was reading Peter Van Roys excellent Concepts, Techniques and Models of Computer Programming, but I'm glad I did.

Having said that, I've never actually used it for anything substantial.

I couldn't either, til I discovered Alice, which is feature compatible but is an SML.

I have "ported" my knowledge to Common Lisp and use it there; but I have been actively re-learning ML for the past few months.

Well, Oz sorta grew up around a textbook on programming paradigms, so that's why they stuffed every conceivable programming paradigm into it. Same goes for the minimal core: since it's intended to illustrate PL concepts, it behooves them to make the core as simple so it doesn't distract from the concepts they're trying to illustrate.

This is why I hate C++

    template<template<class> class f1, template<class> class f2> struct or_combinator

Incidentally, his or_combinator example is more simply expressed thusly:

    or_combinator f1 f2 x = (f1 x) || (f2 x)

This has the same type signature. Anonymous functions are more useful in Haskell when you have some lexical context which needs to be captured and passed around. If partial application suffices, simply use partial application.

I suppose he was trying to demonstrate that the evaluation does not occur until the value is applied though, if the audience was more familiar with C++.

Or even simpler

  or_combinator = liftM2 (||)

but that requires Haskell knowledge to understand. So you might see it in production code, but your version is the right one for the blog. And the original author's version may be even better for comprehension by C++ programmers.

When you get templates working, it does feel pretty good - you can get an approximation of the power of functional languages, all the while knowing that your code has been directly mapped to assembly.

I don't know if it's as good as writing some neat functional code, but for me it's still fun!

If you get a decent Haskell compiler working, say ghc, you get the same warm-fuzzy assembly-feeling.

Clearly the rational thing to do is to create a Haskell DSL that compiles to C++ template metaprograms.

And port Hakyll to it so my blog can be TYPE SAFE and C++!

That wouldn't fly. The IO monad makes Haskell too conceptually impure to express well in the elegant functional language that is C++ template specialization.

I'm loving Haskell more and more.

Great insight into the relationship between C++ MP and Haskell!

Reply on news.ycombinator.com