Comments on: Haskell is nicer than Scheme

by: Alex

Fri, 27 May 2005 11:58:58 -0700

One advantage of Scheme is the sexpr syntax. This isn’t just useful for macros: it allows you to give a concise representation of just about any kind of data you can imagine. For example, a nice trick in Lispy languages is to write a simple procedure for converting lists such as ‘(p ((class . “foo”)) “Blah blah”) into nicely formatted HTML. This makes it really easy to generate HTML content. In Haskell you have to take a more direct approach, writing a combinator library which allows you to combine HTML generating functions. The combinator library approach often works very well, but sometimes it’s nice to have a real solid data structure to manipulate. Especially if you want to store this data in a file rather than hard-coding it into your program. Of course, you could define a datatype for HTML in Haskell, but it would have a rather less pleasing syntax and there would be no pre-defined functions with which to manipulate it.

There’s an interesting relationship between Scheme’s type system (or lack thereof) and its eager evaluation strategy. You’d think that Scheme (having no static type system) ought to be able to express any function expressible in lambda calculus, and therefore have something of an advantage over Haskell. However, this often is not the case in practice. For example, the Y combinator cannot be given its standard lambda calculus definition in Haskell because it has an infinite type, but in Scheme the standard definition leads to nontermination.

by: Jeffrey Yasskin

Fri, 27 May 2005 15:56:59 -0700

If we want to follow the sexpr style in Haskell, we can write your example as ("p", [("class","foo")], "Blah blah"). The only advantage Scheme gives us now is the symbol type, which lets us drop some quotation marks. If we translate it to more idiomatic (and type-safe) Haskell, we could get p [class "foo"] "Blah blah", given p and class as helper functions. The helper functions could generate the HTML datatype just as easily as raw HTML. The lack of pre-defined functions is a problem, but the Scrap Your Boilerplate project is working on it. In summary, Haskell can handle s-expressions, using tuples to handle non-uniform lists, but it allows you to go beyond them when you want.

by: Alex

Fri, 27 May 2005 16:32:31 -0700

Your first suggestion doesn’t really work. If you use tuples to handle the nesting, you have no way of iterating over the elements of a tuple (and this is pretty much essential if you want to actually do something with the data). You can’t use nested tuples as a replacement for nested lists.

As I said, you can create a custom HTML datatype, and if you like you can create helper functions for creating instances of this type. However, under this approach you either need to have lots of quoting and other line noise (e.g. (makeTag “foo” [(”class”, “foo”)])), or you have to define separate functions for each tag, which is rather a waste of time (although I suppose you could just do it for 10 or 20 of the most common tags). Still, the bolierplate thingy you link to is very interesting and would certainly make things easier.

by: Alex

Fri, 27 May 2005 16:36:20 -0700

Hmm, reading through my last comment it sounds a bit stronger than I meant it to. I basically take your point that there are pretty good Haskell alternatives to s-expr syntax.

by: Stefan Holdermans

Thu, 29 Sep 2005 02:06:58 -0700

It could be argued that this Scheme version of zip is actually just a heterogeneous transpose. And, of course, transpose can easily be defined in Haskell as well, albeit homogeneously. (Generalizing it to work on hetereogeneous list as well, may very well be possible, but, admittedly, this will surely take some type class trickery. Extensions that add support for generic programming, for instance through structural polymorphism, like Generic Haskell, allow you to write binary zips that operate on a variety of types, not just lists and pairs.)

by: Bob

Tue, 25 Jul 2006 18:31:20 -0700

I don’t think this comparison of guile’s map1 to haskell’s map is entirely fair, since in scheme I would just directly convert the purely functional map primitive into a tail recursive version without using set-car! and such.

eg. using

(define (map f lst)
   (let loop ((lst lst)
              (res '()))
     (if (null? lst)
       (reverse res)
       (loop (cdr lst)
             (cons (f (car lst)) res)))))

instead of:

(define (map f lst)
   (if (null? lst)
     lst
     (cons (f (car lst))
           (map f (cdr lst)))))

I know it’s non idiomatic, but I would also consider defining lazy-map in scheme, (I use a purely functional implementation of delay and force) and I would be open to using foldr to implement map, one of those would be preferable.

I would be interested to learn more about sexpr-like prefix syntax in haskell, maybe I am crazy but I really don’t care for complex syntaxes.