Hacker News Reader

Comment by scottmsul | Hacker News Reader

Would it be possible to do the same thing in Haskell using partial function application, where the first argument is the name of the tag and the second argument makes the "<" ">" tags and applies string concatenation?

View on HN

Absolutely. However, I will note that, while Haskell makes partial application very easy, there's also nothing Haskell-specific about it: you can write curried functions in many languages, possibly by using helper functions or just manually transforming your code:

    def tag(tag):
        def render(*body):
            return '<{tag}>{body}</{tag}>'.format(
                tag=tag, body=''.join(body))
        return render

    html = tag('html')
    body = tag('body')
    h1 = tag('h1')
    p = tag('p')

I also should note that, while the macros in this case could be obviated by approaching the problem slightly differently, I don't think that's true of Lisp macros in general. I don't want to be be too harsh to this particular blog post—coming up with a two-or-three line motivating example that's accessible to a general audience without being contrived is very hard! But one consequence of the slightly-contrived nature of the example in this post is that it's very easy to come up with non-macro ways of solving the same problem, as demonstrated above.

You could get most of the value in Haskell using higher-order functions, but note that the macro-based code generates a complete function definition from (deftag tagname). Since definitions aren't values in Haskell (code isn't data), you can't just write

  deftag "html"

but instead would have to write something like

  html = tag "html"

I'm not sure whether you could get around that limitation using Template Haskell (never tried it).

Haskell comes from a family of languages called ML. And ML was known as Lisp without parentheses.

So its again Lisp all over again.

I don't know that I've ever seen someone call ML "Lisp without parentheses". Regardless, even with some familial relationship and a few principles in common (like a commitment to functional programming) the two lineages are far more different than they are alike: Lisp has a powerful dynamic core and intricate metaprogramming capabilities, while Haskell builds on a powerful type system and non-strict evaluation. Saying that Haskell is "Lisp all over again" is sort of like saying that cars are "trains all over again": a statement so reductive, it's somewhere between wrong and nonsensical!

>>I don't know that I've ever seen someone call ML "Lisp without parentheses".

My bad. It's called Lisp with types. From: https://en.wikipedia.org/wiki/ML_(programming_language)

Now. Haskell does look like a impractical scheme. Beyond that, today if you want it, you have typed racket.

For a lot of people you could just go ahead use Racket/Lisp instead of Haskell instead.

Reply on news.ycombinator.com