5 ms·
What Does Haskell Have to Do with C++?
- dfox 16y agoI 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.
- jules 16y agoThis happens in a ton of languages, e.g. Ruby (method call syntax and blocks), Scala (idem), C# (LINQ syntax), etc.
- eru 16y agoTemplate Haskell (or a more general pre-processor) can eliminate most of these discussions, too.
- pmr_ 16y agoNice 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).
- Zak 16y agoThe 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.
- dfox 16y agoIn 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).
- swolchok 16y agoA quick Google doesn't turn up any pages stating that parsing Perl and CL is undecidable. Can you provide a reference?
- nkurz 16y agoI 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 http://www.perlmonks.org/?node_id=663393
- deleted 16y ago[deleted]
- swolchok 16y agoOops! I meant that Google didn't turn up anything for TeX, not Perl. The Perl stuff is indeed well known.
- dfox 16y agoThere 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).
- DannoHung 16y agoThis 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++.
- eru 16y agoOr 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.
- andymorris 16y agoWhen 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!
- eru 16y agoIf you get a decent Haskell compiler working, say ghc, you get the same warm-fuzzy assembly-feeling.
- sgt 16y agoI'm loving Haskell more and more.
- ben0x539 16y agoClearly the rational thing to do is to create a Haskell DSL that compiles to C++ template metaprograms.
- jfb 16y agoAnd port Hakyll to it so my blog can be TYPE SAFE and C++!
- prodigal_erik 16y agoThat wouldn't fly. The IO monad makes Haskell too conceptually impure to express well in the elegant functional language that is C++ template specialization.
- jaywalker 16y agoGreat insight into the relationship between C++ MP and Haskell!