Translating Haskell to C++ metaprogramming • Hacker News Board

Re: Translating Haskell to C++ metaprogramming

#21

Post by igravious » Mon, Jul 13, 2015, 1:37 AM UTC

oever wrote: post #6

cies wrote: post #3

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 R…

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++ templa…

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?

Re: Translating Haskell to C++ metaprogramming

#22

Post by gaze » Mon, Jul 13, 2015, 1:40 AM UTC

igravious wrote: post #21

oever wrote: post #6

Earlier quoted context omitted.

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++ templa…

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?

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

Re: Translating Haskell to C++ metaprogramming

#23

Post by SamReidHughes » Mon, Jul 13, 2015, 1:45 AM UTC

codygman wrote: post #12

SamReidHughes wrote: post #10

Earlier quoted context omitted.

Haskell's perceived as an impractical language because it is one †. There aren't many projects where you'd get any plausible benefit from using Haskell instead of some other reasonable garbage collected language. Lazy evaluation is a big risk, if you aren't writing programs that start and finish. It sure is one that I've suffered from. At the line-by-line level, purely functional code also takes more effort to edit,…

> Haskell's perceived as an impractical language because it is one †. Theoretically maybe ;) The real world disagrees with you however: https://www.fpcomplete.com/business/haskell-industry/ https://wiki.haskell.org/Haskell_in_industry > At the line-by-line level, purely functional code also takes more effort to edit, once written, than imperative code. How? You can locally reason about purely functional code which ma…

The spooky danger comes from lazy evaluation.

The "line-by-line" level has nothing to do with global mutable state. It has to do with locally mutable state. It's a lot simpler to change code that is written in terms of for loops and accumulator variables, than it is to change code written in terms of maps, folds, intercalates, whatever.

In any reasonably architected software, you can see how a function depends on global state by looking at its argument list. Those that use database connections take the database connection. Those that create database connections receive a parameter that tells them what to connect to. Pretty much everything writes log messages. If you're in a position to choose Haskell, then you're also in a position to make your software this way.

Re: Translating Haskell to C++ metaprogramming

#24

Post by igravious » Mon, Jul 13, 2015, 1:56 AM UTC

gaze wrote: post #22

igravious wrote: post #21

Earlier quoted context omitted.

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?

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

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

Re: Translating Haskell to C++ metaprogramming

#25

Post by raphaelss » Mon, Jul 13, 2015, 2:01 AM UTC

notthemessiah wrote: post #19

raphaelss wrote: post #11

Earlier quoted context omitted.

Thank you. Haskell is no bed of roses and C++ is not all that bad. Some of us write real time signal processing code and C++ is a viable choice in this context.

"Bed of roses" seems like a weird idiom because roses have thorns.

True. I did not think about it this way and just went with a common expression.

Feel free to read it as "Haskell isn't all sunshine and rainbows."

To be clear (before you say that "sunshine and rainbows" seems like a weird idiom because sunshine causes cancer), I meant that I think Haskell also has disadvantages.

Re: Translating Haskell to C++ metaprogramming

#26

Post by Nullabillity » Mon, Jul 13, 2015, 2:03 AM UTC

igravious wrote: post #24

gaze wrote: post #22

Earlier quoted context omitted.

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

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

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.

Re: Translating Haskell to C++ metaprogramming

#27

Post by gizmo686 » Mon, Jul 13, 2015, 2:09 AM UTC

igravious wrote: post #21

oever wrote: post #6

Earlier quoted context omitted.

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++ templa…

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?

    contains :: (NameClass, QName) -> Bool

is valid Haskel, and denotes that "contains" is a function that takes a tuple and returns a bool. As a matter of style, Haskellers tend to avoid writing function like this, and prefer to write functions like

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

which indicates that "contains" is a function that takes a "NameClass" and returns another function. Because this pattern is so common in Haskell, -> is defined to be right-associative, so the paranthese can be omited.

Re: Translating Haskell to C++ metaprogramming

#28

Post by banachtarski » Mon, Jul 13, 2015, 2:17 AM UTC

oever wrote: post #7

jlarocco wrote: post #2

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 wit…

Haskell is a great language. But there are large codebases out there in C++. Porting those is often not feasible. Yet, Haskell can serve as a great inspiration of how to write clean code. C++ does not have the limitations/strictness of Haskell, but that does not mean that a programmer cannot apply the rigor of Haskell to C++ code. Blasien is meant as a way to improve software that works with XML. Big packages like Li…

Agreed. While I would never use Haskell to, say, right a next gen graphics engine, I can confidently say that learning to write idiomatic Haskell code has improved my C++ code.

Re: Translating Haskell to C++ metaprogramming

#29

Post by notthemessiah » Mon, Jul 13, 2015, 2:22 AM UTC

raphaelss wrote: post #25

notthemessiah wrote: post #19

Earlier quoted context omitted.

"Bed of roses" seems like a weird idiom because roses have thorns.

True. I did not think about it this way and just went with a common expression. Feel free to read it as "Haskell isn't all sunshine and rainbows." To be clear (before you say that "sunshine and rainbows" seems like a weird idiom because sunshine causes cancer), I meant that I think Haskell also has disadvantages.

Makes more sense when you look into the etymology.

https://en.wiktionary.org/wiki/bed#Etymology

from Old English bedd (“bed, couch, resting-place; garden-bed, plot”)

Re: Translating Haskell to C++ metaprogramming

#30

Post by theseoafs » Mon, Jul 13, 2015, 2:29 AM UTC

Nullabillity wrote: post #26

igravious wrote: post #24

Earlier quoted context omitted.

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

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.

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.