7 ms·

Why Lisp is a Big Hack (And Haskell is Doomed to Succeed)

110 points by yewweitan 16y ago

lispm 16y ago
Last time I looked Haskell and Lisp were totally different languages, with different communities, different technologies, different application areas, ... Why should this change?
kunjaan 16y ago
If he favors type safety and switching between modules of different type systems, Racket already has that, doesn't it?
- pwpwp 16y ago
  Good point - I forgot to consider this approach. I'll have come back to it at another point. Generally though, I think Haskell's approach of re-adding freedoms is more fruitful than trying to add bondage to Lisp. And "the Haskell movement" certainly has a different kind of manpower behind it.
  - kunjaan 16y ago
    >And "the Haskell movement" certainly has a different kind of manpower behind it. Can you clarify what you mean by the words "movement" and "different kind of manpower"? How is progress in languages like Racket different from Haskell? Why do you think that adding "interesting" type systems in Lisp would be "heroic" and less "fruitful"?
    - pwpwp 16y ago
      There are probably hundreds, if not thousands of researchers, who use Haskell (and related PLs) as their vehicle for type system research. People working on "gradual" type systems like Typed Racket are probably around a dozen, which means that progress in Haskell happens much faster and with more breadth.
      - jneira 16y ago
        and what about http://en.wikipedia.org/wiki/Qi_%28programming_language%29 http://en.wikipedia.org/wiki/Qi_%28programming_language%29 (via @fogus)?? Choose haskell as the only way to programming nirvana could be eliminate other differents points of view. In fact choose whatever will do
        thesz 16y ago
        When my post started a heated conversation in ru_lisp LiveJournal community, someone told there about his personal experience with Qi. He managed to convince Qi that 42 is of type String. That's the price of freedom of Lisp.
      - Raphael_Amiard 16y ago
        While i think you make valid points, i do not agree with the conclusion. First, i don't think associating innovativity with numbers of researchers is a safe predicate since it's clearly not linear. Second, the fact that haskell is a testbed for researchers doesn't make it the ideal language for "real world programming" in my opinion. It could be that it is, but again the correlation is less than clear. And third, and that's the most important point in my opinion, the ideas developped in haskell are fully available to other language implementors once they exist, and the experience of researchers is available. It means that a language like typed racket or any other could possibly implement the best/most usefull of those ideas in much less time than was needed to first find them.
        thesz 16y ago
        >Second, the fact that haskell is a testbed for researchers doesn't make it the ideal language for "real world programming" in my opinion. Once upon a time Lisp was a language for researchers.
        kunjaan 16y ago
        It still is.
- naradaellis 16y ago
  He argues that some features - e.g., dependent typing (http://axisofeval.blogspot.com/2010/10/notes-on-dependent-types.html http://axisofeval.blogspot.com/2010/10/notes-on-dependent-ty...) - won't emerge from Lisp, because they approach the problem from the wrong angle; no safety towards more safe vs. Haskell (and others') reverse approach.
Confusion 16y ago
Greenspun's Tenth Rule of Programming Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp. Replace C by Lisp and CL by Haskell? Rinse, lather, repeat every few decades?
- gsivil 16y ago
  Can you please give us some historical examples where this quote could be applied? This would be interesting to know.
  - abrahamsen 16y ago
    AutoCAD and Emacs would be literal examples of "sufficiently advanced" C programs by this definition. My guess is that it is intended to cover any C or Fortran program that includes an ad-hoc interpreter, an ad-hoc dynamic type system, or an ad-hoc garbage collector. That would include e.g. sendmail (at least an ad-hoc interpreter) and GCC (all three). My guess is that most C programs (I don't know about Fortran) we would intuitively call "complex" contains one of the three technologies, making it harder to come up with a clear counter-example. Some might avoid the "ad-hoc" part by linking with a generic extension language like tcl or lua. Or even Common Lisp.
    - wisty 16y ago
      Well, almost any big traditional application (not really web apps) eventually grows a scripting language for extensions and / or user macros. Basic (in Office), Javascript and Java (in web browsers), Lisp (in the above applications, and probably many more), Lua (in a lot of games), AppleScript, that C thingy in Quake ... Lisp is relatively easy to implement, powerful, and intuitive to non-programmers (compared to OOP - Python, Perl, and Ruby are also easy but nowhere near as old); so it's a common choice.
      - ckwop 16y ago
        I didn't believe this "Easy to implement" line but over Christmas I wrote my own LISP implementation on top of .NET and it comes to about 350 lines codes. That includes all the list operations, an arbitrary precision number type and a host of the usual built in function (add, subtract, multiply, divide, and not or etc). Eye-opening to say the least!
dexen 16y ago
This is the first time I feel PG's `The Hundred-Year Language' may have answer different than Lisp. On the other hand, `a witty blogpost proves nothing', to misquote somebody.
- pwpwp 16y ago
  The great thing is: if and when Haskell ever evolves as far as described in the post, we'll have Lisp again - inside "Haskell". ;)
  - Locke1689 16y ago
    Looking at it that way is ignoring all the benefits that Haskell can offer over Lisp. If all you can think in is Lisp then you're doomed to write Lisp in any language, to turn a phrase.
  - andreyf 16y ago
    No. Haskell has type safety which was never intended to be included in Lisp. On the other hand, Lisp has the s-expression syntax which allows for usable compile-time macros. Neither language is a subset of the other. How useful type checking and macros are in creating real-world software is not a question I've seen answered well. Smalltalk-style languages (Python, Ruby) don't really practice either.
    - pmarin 16y ago
      "Haskell has type safety which was never intended to be included in Lisp." Racket has a dialect with static types. http://docs.racket-lang.org/ts-guide/ http://docs.racket-lang.org/ts-guide/
      - deleted 16y ago
        [deleted]
    - Mathnerd314 16y ago
      Haskell has Template Haskell, which is (almost) as usable as Lisp macros.
jaekwon 16y ago
Of course you have to subscribe to the idea that this safety and verification is something that's good and superior. I do. Why is it superior? I've always believed that a superior language is one that is as close to natural language as possible. Natural language doesn't have strict type checking, and a great many things were told with 'incorrect' grammar.
- coderdude 16y ago
  Natural language has ambiguity. That kills its effectiveness as a programming language.
  - varjag 16y ago
    It would be interesting to see how many Haskell programmers are also Lojban speakers.
    - Wilfred 16y ago
      Funny you should mention that. There was a survey of favoured web frameworks[1] in the Lojban community, and Haskell with snap won[2]. 1: http://www.surveymonkey.com/s/T6B69LK http://www.surveymonkey.com/s/T6B69LK 2: http://teddyb.org/~rlpowell/public_media/lojban_survey.PNG http://teddyb.org/~rlpowell/public_media/lojban_survey.PNG
  - jaekwon 16y ago
    Solvable if the compiler can initiate an intelligent conversation. Like, "What you said is ambiguous. Did you mean? ..."
    - dexen 16y ago
      Do you envision search engines becoming Turing complete at some point in time? ;-)
      - jaekwon 16y ago
sfvisser 16y ago
As a Haskell programmer I never feel the need to add any form of dynamic typing. In practice dynamic typing makes it harder to build programs, not easier. I'm the first one to admit that Haskell's type system has a somewhat steep learning curve. But after a while, when you internalize it and learn to pattern match on GHC's type errors, day-to-day programming will become easier.
- lelele 16y ago
  > In practice dynamic typing makes it harder to build programs, not easier. OTOH, static typing could make writing some kinds of programs impossible. In an interview, Joe Armstrong of Erlang fame said that they tried hard to put a type-system on top of Erlang, but they have not been able to. IMO, static-typing should be optional, that is: you should be able to run a static-typing checker on your programs, without being constrained by it at every step.
  - hesselink 16y ago
    > OTOH, static typing could make writing some kinds of programs impossible. Often, these turn out to be incorrect programs or programs without a good structure/architecture. It is my experience that static typing makes it slightly harder to write the first version of a program, but subsequent alterations become an order of magnitude easier. For me, this is worth it, since alteration and maintenance are the largest part of most program's life cycles.
    - lelele 16y ago
      > Often, these turn out to be incorrect programs or programs without a good structure/architecture. Then this critique would apply to most - all? - Erlang programs too ;-)
  - thesz 16y ago
    No, JA told that they planned to add type system, but their users didn't feel they need it. And, actually, they added types into Erlang: dyalizer. As for optionality of static types... What is your experience, precisely? My tells me that type systems are, actually, your partners in program development. Quite intelligent partners - Haskell type system, Agda2 type system...
kleiba 16y ago
There's always a trade-off between the expressablity of a programming language and its complexity. I think Lisp may (still) have a slight advantage when it comes to that balance, i.e., it is more accessible for novices. And adding more things to an already complex language like Haskell doesn't sound like changing that balance in the latter's favor.
raganwald 16y ago
Let me see if I understand this: The argument is that a hypothetical language descending from Haskell will be (a) superior and (b) more popular than Lisp as we know it today and to any Lisp that might evolve from it. I think there's too much hand-waving going on to agree or disagree with the premise. Language popularity is notoriously fickle and driven by considerations that don't even earn a footnote in the OP. For example, one of the most popular languages in the world today is Javascript, a language that owes a little of its heritage to Lisp and none at all to Haskell. Why is it eating Lisp's lunch and Haskell's lunch today? Because it ships as the default runtime for the most popular application in the world, the web browser. Another language that has the same breadth of reach is PHP. Again, its popularity is due to the fact that it is a default runtime for most of the world's hosted web server platforms. If we are to guess which language is going to gorge itself on everyone else's lunches in the future, I would suggest we spend our time thinking about which platform is going to be insanely popular and what new language might be its default runtime. I'm not providing any fresh insight, of course: Let's start by acknowledging one external factor that does affect the popularity of a programming language. To become popular, a programming language has to be the scripting language of a popular system. Fortran and Cobol were the scripting languages of early IBM mainframes. C was the scripting language of Unix, and so, later, was Perl. Tcl is the scripting language of Tk. Java and Javascript are intended to be the scripting languages of web browsers. http://www.paulgraham.com/popular.html http://www.paulgraham.com/popular.html
- jerf 16y ago
  I agree with your handwaving point. But there is one point worth underlining a bit, which is that you can't start with (traditional) Lisp and then build in something that can only be built based on total, guaranteed restriction, because Lisp always lets you out. Haskell's STM is probably the best example; so far I don't think anyone has built a successful imperative STM because if you let people out even a little bit the STM abstraction tends to break. You have to be restricted for that to work in practice, even if in theory you could load that all onto the programmer; the constraints are too hard for a programmer to just implement, let alone a team. You can write macros in Lisp to implement these restrictions, of course, but they will be hard to make water-tight, and then you will be left unable to use anybody else's libraries because they will not honor these restrictions. If there is anything Lisp can't do, any language in moderately common use that it is not strictly superior to, it is Haskell. You can not just turn Lisp into Haskell with a few well-chosen macros, or even a lot of macros, without making it Not Lisp Anymore. It may have taken a while, but we finally have a modestly practical language that is not merely Lisp warmed over or Lisp horrifically subsetted and bastardized; it's genuinely something different.
voxcogitatio 16y ago
I'm not sure that Haskell could, given time, subsume dynamically typed programming. But even if it is possible, why would it be desirable? Most Haskell people don't think very highly of dynamic typing, and the extensions to the language reflect that. They generally add more typing, e.g GADT's, multi-parameter type classes, extensible kinds e.t.c. And dependent typing is certainly not a move towards dynamic typing! Casting it as such shows poor understanding of both concepts.
ramanujan 16y ago
What we really need is for some people to turbocharge ghcjs (http://news.ycombinator.com/item?id=1818820 http://news.ycombinator.com/item?id=1818820), so that we can get optional static type checking in Javascript. Haskell is great at parsing[1] and great at type checking. So how about it parse the relatively simple JS grammar[2] and do some static checking on JS code? You could augment existing JS code with an optional accepts/return syntax to provide type annotations: foo = function(x) { return [x+1,x+2]} foo.accepts = Numeric foo.returns = [Numeric, Numeric] This is similar to Collin Winter's typecheck for python (http://pypi.python.org/pypi/typecheck/ http://pypi.python.org/pypi/typecheck/), which has some nontrivial bugs but which is conceptually interesting. [1] You could use Matt Might's new derivative parser if you want to have some fun while doing this (he has a Haskell implementation to boot!) http://matt.might.net/articles/parsing-with-derivatives/ http://matt.might.net/articles/parsing-with-derivatives/ [2] Real World Haskell has a good JSON example that should be easily extensible to the full syntax: http://book.realworldhaskell.org/read/writing-a-library-working-with-json-data.html http://book.realworldhaskell.org/read/writing-a-library-work... EDIT: Doctor JS by Mozilla is a (very) good start here -- maybe it already does everything we need... http://doctorjs.org http://doctorjs.org

110 points by yewweitan 16y ago

lispm 16y ago

Last time I looked Haskell and Lisp were totally different languages, with different communities, different technologies, different application areas, ... Why should this change?

kunjaan 16y ago

If he favors type safety and switching between modules of different type systems, Racket already has that, doesn't it?

pwpwp 16y ago
Good point - I forgot to consider this approach. I'll have come back to it at another point. Generally though, I think Haskell's approach of re-adding freedoms is more fruitful than trying to add bondage to Lisp. And "the Haskell movement" certainly has a different kind of manpower behind it.
- kunjaan 16y ago
  >And "the Haskell movement" certainly has a different kind of manpower behind it. Can you clarify what you mean by the words "movement" and "different kind of manpower"? How is progress in languages like Racket different from Haskell? Why do you think that adding "interesting" type systems in Lisp would be "heroic" and less "fruitful"?
  - pwpwp 16y ago
    There are probably hundreds, if not thousands of researchers, who use Haskell (and related PLs) as their vehicle for type system research. People working on "gradual" type systems like Typed Racket are probably around a dozen, which means that progress in Haskell happens much faster and with more breadth.
    - jneira 16y ago
      and what about http://en.wikipedia.org/wiki/Qi_%28programming_language%29 http://en.wikipedia.org/wiki/Qi_%28programming_language%29 (via @fogus)?? Choose haskell as the only way to programming nirvana could be eliminate other differents points of view. In fact choose whatever will do
      - thesz 16y ago
        When my post started a heated conversation in ru_lisp LiveJournal community, someone told there about his personal experience with Qi. He managed to convince Qi that 42 is of type String. That's the price of freedom of Lisp.
    - Raphael_Amiard 16y ago
      While i think you make valid points, i do not agree with the conclusion. First, i don't think associating innovativity with numbers of researchers is a safe predicate since it's clearly not linear. Second, the fact that haskell is a testbed for researchers doesn't make it the ideal language for "real world programming" in my opinion. It could be that it is, but again the correlation is less than clear. And third, and that's the most important point in my opinion, the ideas developped in haskell are fully available to other language implementors once they exist, and the experience of researchers is available. It means that a language like typed racket or any other could possibly implement the best/most usefull of those ideas in much less time than was needed to first find them.
      - thesz 16y ago
        >Second, the fact that haskell is a testbed for researchers doesn't make it the ideal language for "real world programming" in my opinion. Once upon a time Lisp was a language for researchers.
        kunjaan 16y ago
        It still is.
naradaellis 16y ago
He argues that some features - e.g., dependent typing (http://axisofeval.blogspot.com/2010/10/notes-on-dependent-types.html http://axisofeval.blogspot.com/2010/10/notes-on-dependent-ty...) - won't emerge from Lisp, because they approach the problem from the wrong angle; no safety towards more safe vs. Haskell (and others') reverse approach.

Confusion 16y ago

Greenspun's Tenth Rule of Programming Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp. Replace C by Lisp and CL by Haskell? Rinse, lather, repeat every few decades?

gsivil 16y ago
Can you please give us some historical examples where this quote could be applied? This would be interesting to know.
- abrahamsen 16y ago
  AutoCAD and Emacs would be literal examples of "sufficiently advanced" C programs by this definition. My guess is that it is intended to cover any C or Fortran program that includes an ad-hoc interpreter, an ad-hoc dynamic type system, or an ad-hoc garbage collector. That would include e.g. sendmail (at least an ad-hoc interpreter) and GCC (all three). My guess is that most C programs (I don't know about Fortran) we would intuitively call "complex" contains one of the three technologies, making it harder to come up with a clear counter-example. Some might avoid the "ad-hoc" part by linking with a generic extension language like tcl or lua. Or even Common Lisp.
  - wisty 16y ago
    Well, almost any big traditional application (not really web apps) eventually grows a scripting language for extensions and / or user macros. Basic (in Office), Javascript and Java (in web browsers), Lisp (in the above applications, and probably many more), Lua (in a lot of games), AppleScript, that C thingy in Quake ... Lisp is relatively easy to implement, powerful, and intuitive to non-programmers (compared to OOP - Python, Perl, and Ruby are also easy but nowhere near as old); so it's a common choice.
    - ckwop 16y ago
      I didn't believe this "Easy to implement" line but over Christmas I wrote my own LISP implementation on top of .NET and it comes to about 350 lines codes. That includes all the list operations, an arbitrary precision number type and a host of the usual built in function (add, subtract, multiply, divide, and not or etc). Eye-opening to say the least!

dexen 16y ago

This is the first time I feel PG's `The Hundred-Year Language' may have answer different than Lisp. On the other hand, `a witty blogpost proves nothing', to misquote somebody.

pwpwp 16y ago
The great thing is: if and when Haskell ever evolves as far as described in the post, we'll have Lisp again - inside "Haskell". ;)
- Locke1689 16y ago
  Looking at it that way is ignoring all the benefits that Haskell can offer over Lisp. If all you can think in is Lisp then you're doomed to write Lisp in any language, to turn a phrase.
- andreyf 16y ago
  No. Haskell has type safety which was never intended to be included in Lisp. On the other hand, Lisp has the s-expression syntax which allows for usable compile-time macros. Neither language is a subset of the other. How useful type checking and macros are in creating real-world software is not a question I've seen answered well. Smalltalk-style languages (Python, Ruby) don't really practice either.
  - pmarin 16y ago
    "Haskell has type safety which was never intended to be included in Lisp." Racket has a dialect with static types. http://docs.racket-lang.org/ts-guide/ http://docs.racket-lang.org/ts-guide/
    - deleted 16y ago
      [deleted]
  - Mathnerd314 16y ago
    Haskell has Template Haskell, which is (almost) as usable as Lisp macros.

jaekwon 16y ago

Of course you have to subscribe to the idea that this safety and verification is something that's good and superior. I do. Why is it superior? I've always believed that a superior language is one that is as close to natural language as possible. Natural language doesn't have strict type checking, and a great many things were told with 'incorrect' grammar.

coderdude 16y ago
Natural language has ambiguity. That kills its effectiveness as a programming language.
- varjag 16y ago
  It would be interesting to see how many Haskell programmers are also Lojban speakers.
  - Wilfred 16y ago
    Funny you should mention that. There was a survey of favoured web frameworks[1] in the Lojban community, and Haskell with snap won[2]. 1: http://www.surveymonkey.com/s/T6B69LK http://www.surveymonkey.com/s/T6B69LK 2: http://teddyb.org/~rlpowell/public_media/lojban_survey.PNG http://teddyb.org/~rlpowell/public_media/lojban_survey.PNG
- jaekwon 16y ago
  Solvable if the compiler can initiate an intelligent conversation. Like, "What you said is ambiguous. Did you mean? ..."
  - dexen 16y ago
    Do you envision search engines becoming Turing complete at some point in time? ;-)
    - jaekwon 16y ago

sfvisser 16y ago

As a Haskell programmer I never feel the need to add any form of dynamic typing. In practice dynamic typing makes it harder to build programs, not easier. I'm the first one to admit that Haskell's type system has a somewhat steep learning curve. But after a while, when you internalize it and learn to pattern match on GHC's type errors, day-to-day programming will become easier.

lelele 16y ago
> In practice dynamic typing makes it harder to build programs, not easier. OTOH, static typing could make writing some kinds of programs impossible. In an interview, Joe Armstrong of Erlang fame said that they tried hard to put a type-system on top of Erlang, but they have not been able to. IMO, static-typing should be optional, that is: you should be able to run a static-typing checker on your programs, without being constrained by it at every step.
- hesselink 16y ago
  > OTOH, static typing could make writing some kinds of programs impossible. Often, these turn out to be incorrect programs or programs without a good structure/architecture. It is my experience that static typing makes it slightly harder to write the first version of a program, but subsequent alterations become an order of magnitude easier. For me, this is worth it, since alteration and maintenance are the largest part of most program's life cycles.
  - lelele 16y ago
    > Often, these turn out to be incorrect programs or programs without a good structure/architecture. Then this critique would apply to most - all? - Erlang programs too ;-)
- thesz 16y ago
  No, JA told that they planned to add type system, but their users didn't feel they need it. And, actually, they added types into Erlang: dyalizer. As for optionality of static types... What is your experience, precisely? My tells me that type systems are, actually, your partners in program development. Quite intelligent partners - Haskell type system, Agda2 type system...

kleiba 16y ago

There's always a trade-off between the expressablity of a programming language and its complexity. I think Lisp may (still) have a slight advantage when it comes to that balance, i.e., it is more accessible for novices. And adding more things to an already complex language like Haskell doesn't sound like changing that balance in the latter's favor.

raganwald 16y ago

Let me see if I understand this: The argument is that a hypothetical language descending from Haskell will be (a) superior and (b) more popular than Lisp as we know it today and to any Lisp that might evolve from it. I think there's too much hand-waving going on to agree or disagree with the premise. Language popularity is notoriously fickle and driven by considerations that don't even earn a footnote in the OP. For example, one of the most popular languages in the world today is Javascript, a language that owes a little of its heritage to Lisp and none at all to Haskell. Why is it eating Lisp's lunch and Haskell's lunch today? Because it ships as the default runtime for the most popular application in the world, the web browser. Another language that has the same breadth of reach is PHP. Again, its popularity is due to the fact that it is a default runtime for most of the world's hosted web server platforms. If we are to guess which language is going to gorge itself on everyone else's lunches in the future, I would suggest we spend our time thinking about which platform is going to be insanely popular and what new language might be its default runtime. I'm not providing any fresh insight, of course: Let's start by acknowledging one external factor that does affect the popularity of a programming language. To become popular, a programming language has to be the scripting language of a popular system. Fortran and Cobol were the scripting languages of early IBM mainframes. C was the scripting language of Unix, and so, later, was Perl. Tcl is the scripting language of Tk. Java and Javascript are intended to be the scripting languages of web browsers. http://www.paulgraham.com/popular.html http://www.paulgraham.com/popular.html

jerf 16y ago
I agree with your handwaving point. But there is one point worth underlining a bit, which is that you can't start with (traditional) Lisp and then build in something that can only be built based on total, guaranteed restriction, because Lisp always lets you out. Haskell's STM is probably the best example; so far I don't think anyone has built a successful imperative STM because if you let people out even a little bit the STM abstraction tends to break. You have to be restricted for that to work in practice, even if in theory you could load that all onto the programmer; the constraints are too hard for a programmer to just implement, let alone a team. You can write macros in Lisp to implement these restrictions, of course, but they will be hard to make water-tight, and then you will be left unable to use anybody else's libraries because they will not honor these restrictions. If there is anything Lisp can't do, any language in moderately common use that it is not strictly superior to, it is Haskell. You can not just turn Lisp into Haskell with a few well-chosen macros, or even a lot of macros, without making it Not Lisp Anymore. It may have taken a while, but we finally have a modestly practical language that is not merely Lisp warmed over or Lisp horrifically subsetted and bastardized; it's genuinely something different.

voxcogitatio 16y ago

I'm not sure that Haskell could, given time, subsume dynamically typed programming. But even if it is possible, why would it be desirable? Most Haskell people don't think very highly of dynamic typing, and the extensions to the language reflect that. They generally add more typing, e.g GADT's, multi-parameter type classes, extensible kinds e.t.c. And dependent typing is certainly not a move towards dynamic typing! Casting it as such shows poor understanding of both concepts.

ramanujan 16y ago

What we really need is for some people to turbocharge ghcjs (http://news.ycombinator.com/item?id=1818820 http://news.ycombinator.com/item?id=1818820), so that we can get optional static type checking in Javascript. Haskell is great at parsing[1] and great at type checking. So how about it parse the relatively simple JS grammar[2] and do some static checking on JS code? You could augment existing JS code with an optional accepts/return syntax to provide type annotations: foo = function(x) { return [x+1,x+2]} foo.accepts = Numeric foo.returns = [Numeric, Numeric] This is similar to Collin Winter's typecheck for python (http://pypi.python.org/pypi/typecheck/ http://pypi.python.org/pypi/typecheck/), which has some nontrivial bugs but which is conceptually interesting. [1] You could use Matt Might's new derivative parser if you want to have some fun while doing this (he has a Haskell implementation to boot!) http://matt.might.net/articles/parsing-with-derivatives/ http://matt.might.net/articles/parsing-with-derivatives/ [2] Real World Haskell has a good JSON example that should be easily extensible to the full syntax: http://book.realworldhaskell.org/read/writing-a-library-working-with-json-data.html http://book.realworldhaskell.org/read/writing-a-library-work... EDIT: Doctor JS by Mozilla is a (very) good start here -- maybe it already does everything we need... http://doctorjs.org http://doctorjs.org