
Translating Haskell to C++ metaprogramming - oever
http://www.vandenoever.info/blog/2015/07/12/translating-haskell-to-c++.html
======
gergoerdi
I did a barebones Haskell to C++ template compiler as a fun diversion once,
see
[http://gergo.erdi.hu/projects/metafun/](http://gergo.erdi.hu/projects/metafun/)
If I understand right, this guy is doing this by hand -- why not just extend
MetaFun for whatever language constructs he needs to use that are not yet
supported by MetaFun?

------
jlarocco
I don't know why people don't just use Haskell.

C++'s template system has become the ugliest part of the language, both the
syntax and the perverse ways people twist the language with it. I understand
most of the metaprogramming tricks are in the same vein as "Look what I made
in Brainfuck!", and are more about showing off than for serious consideration,
but for getting real work done it's a huge headache to work with, and the
effort would be better spent doing more interesting things in languages that
weren't so hard to use. And it's not every day that I suggest Haskell is
easier than something else :-)

~~~
banachtarski
I'll explain it to you, as a person who was a Haskell enthusiast and uses C++
professionally.

The problem with Haskell is that while it is very effective at expressing
_ideas_ and _logic_ , it is just as ineffective at expressing _runtime
behavior_. In world where everything is lazily evaluated by default and
garbage collected, it is very difficult to reason about how the code will
actually execute. Are you trashing the cache? Fragmenting your heap? Are you
misusing the instruction cache? For performance reasons, Haskell programmers
often need to forcibly make operations strict and turn off the thunk
essentially. This is a layer of complexity you don't often see in blogposts
and Haskell tutorials. In contrast, I can look at C or C++ code and tell you
more or less exactly how it will map to assembly (with some exceptions like
when compilers decide to inline).

So in short, that Haskell you know is not the full story. I've written some
Haskell programs and tried very, very hard to make them fast (they were
parallelized too). At the end of the day, it's hard for a language to
completely outclass another one because there are tradeoffs and life isn't so
simple.

~~~
jlarocco
That reply came off a little condescending.

I'm not some kind of Haskell zealot, and I haven't even used it in several
years. That said, I'm well aware of the downsides of Haskell, and I've pointed
out on numerous occasions that "real life" Haskell doesn't match up with the
pure, lazy Haskell people often talk about.

However, the reality is that people who really care about performance and
predictability in C++ aren't doing crazy template metaprogramming because,
although not as bad as Haskell, it's also difficult to reason about and
understand what's going on under the hood.

My guess is that every time somebody has said, "I translated this Haskell code
to C++ metaprogramming," they could have just used Haskell with no negative
repercussions.

~~~
banachtarski
I think that's probably mostly accurate.

That said, I do use templated code in my inner loops even. After all, the
benefit of generics is that you do the work at compile time instead of runtime
(no casting, data marshalling is tight, etc).

Even with code that needed to be significantly templatized (as is the case
with many core libraries), I have to give C++ a clear edge as far as runtime
debuggability and performance is concerned.

------
harry8
Why is there no usable haskell SSL library? It would seem this is an area
where the claims about haskell eliminating whole classes of bugs and so on
would really be worthwhile and an amazing advert for haskell advocates.

The claims about being able to formally prove the code implements the spec
would be pretty damn compelling in that space too.

Once upon a time I asked on HN if there are any useful and usable haskell
programs you can just install and run for a purpose that isn't writing haskell
code. Shellcheck & pandoc seemed to be the suggested examples. Is that still
the case or are there now a few more?

~~~
tome
Firstly, the entire classes of bugs that Haskell eliminates are not classes
that are especially relevant to cryptography.

Secondly, if you know where someone has claimed that Haskell lets you
"formally prove the code implements the spec" then please point it out to me
so I can challenge them for being misleading at best.

~~~
harry8
Surprising that heartbleed got past you? Or does haskell not eliminate buffer
overflows. I've heard many clam it does.

SeL4. It comes up regularly that C, or java or python or some other well used
language doesn't work well with isabelle, coq because of pointers, destructive
assignment or whatever but haskell is pure and this is one of the many
advantage of pure. I don't have this opinion myself nor have I formed the
opinion that it's false.

------
cies
Please correct me if I'm wrong, but I think the word metaprogramming (MP) is
used a bit too liberal in this article. When I think of MP I think of
programs-writing-programs, which might very well be a too narrow definition.

TemplateHaskell --DSLs that are transformed to (mostly rather repetitive)
Haskell at compile time-- are MP in my idea, also: macros in LISP and open
classes modified my the program at runtime in Ruby.

Non the less a very interesting article! Compared to C++ Haskell's syntax is
soo clean!

~~~
oever
I use the term 'metaprogramming' because that's the title of the relevant
chapter in Stroustrups 'The C++ programming language'. I do think that 'C++
metaprogamming' is a bit clunky, but 'C++ template programming' sounds too
limited. 'compile time programming' also sounds strange.

Wikipedia says: "Metaprogramming is the writing of computer programs with the
ability to treat programs as their data." Writing C++ templates to treat Relax
NG specifications and literal XML in C++ as input for schema validation would
fit that definition.

~~~
igravious
I think 'C++ template programming' might be better also :/

The following syntax in Haskell causes a parse error in my brain:

    
    
        contains :: NameClass -> QName -> Bool
    

I really want it to be

    
    
        contains :: (NameClass, QName) -> Bool
    

Or even just

    
    
        contains :: NameClass, QName -> Bool
    

Is it just my problem to get over or do other people have it, or is there
syntactic sugar coming to my rescue?

~~~
gaze
You should get over it. It's just syntax... and it's there for a reason (Makes
more sense for curried functions, and it's a holdover from logic where you say
that if you have a nameclass, you have an object that sense a qname to a bool,
and if you have a nameclass and a qname then you have a bool.)

~~~
igravious
What? Are you saying that I can legitimately read

    
    
        contains :: NameClass -> QName -> Bool
    

two ways? Like,

    
    
        contains :: (NameClass, QName) -> Bool
    

And

    
    
        contains :: NameClass -> (QName, Bool)
    

? What about four types?

    
    
        contains :: Urk -> NameClass -> QName -> Bool

~~~
Nullabillity
Not quite. It's equivalent to either

    
    
        contains :: (NameClass, QName) -> Bool
    

or

    
    
        contains :: NameClass -> (QName -> Bool)
    

In other words, you can treat it as a function taking two arguments, or one
function taking one argument and returning another function.

~~~
theseoafs
It is equivalent to the second, not the first. The first is a completely
distinct type -- though you can certainly write a function with that type,
given the original function, by uncurrying it.

~~~
saurik
FWIW, I think the person you are responding to is using the non-Haskell
requested mental syntax used by the person who asked the original question, in
order so they better understand the semantics (even if at a cost of confusing
them for later development in Haskell).

~~~
Nullabillity
Yup. They're distinct types, but mentally they are the same (and the standard
library has functions to convert between the two forms).

