Incremental parsing really isn't that hard: just cache the trees and damage/repair appropriately. I'm not sure if Haskell will be much of an advantage there; I found my own frameworks to be incredibly stateful...to the point that I designed Glitch to replace FRP to solve this specific problem.
Incremental parsing is also the first step toward incremental type checking :)
The post is a bit wrong, there have been incremental parsing frameworks in the past (see Tim Wagner and Susan Graham's work on Harmonia at UCB). But I've never been able to use them very well, and the problem is simple enough that cache/damage/repair is good enough (actually for type checking also).
As someone whose ISP enforces a draconian bandwidth limit, I would really like to see an estimate of how much all the dependencies are going to end up costing me.
The last time I tried to build a Haskell program (I think it was on 64-bit Arch linux), I ended up quitting after I broke 800 MB in downloads with no end in sight.
Small, yes, but they just keep coming. As an example, Pandoc has a tree of something like 70 dependencies on Arch? (I can at least tell you that it has 37 direct dependencies)
I have tried a few times in the last year to find someone who something crazier than Yi: a Haskell program that is text editor, IDE, and integrated Webkit browser, all in Haskell. The dev was a former Emacs enthusiast. It looked really cool, but I forgot to bookmark.
It is not Yi, but does anyone know what I am talking about?
looking at these config files I do feel like we're still missing a style to write nice config files in a language like Haskell. I don't think it's a language issue, but there's still a bit of difficulty in the building blocks given by things like xmonad or yi.
Basically, the idea is that Yi is actually a Haskell library, and your "config file" is really a Haskell program that uses this library to build an editor.
This is similar to how many suckless tools are written. If you want to configure them, edit the source: It's designed to be approachable and easy to modify.
This style of configuration is extremely nice IMHO. It gives you complete control over everything in one of the cleanest, most expressive languages around. It also means that you don't need to maintain a separate configuration language, and people that use your software are already taking steps towards becoming contributors.
I remember one where the speaker demoed ... partial? indentation. Changing an L-value[1], shifted the R-values on each keystroke. Haskellers in the room slowly clapped. I was amazed (by both).
I gave a Yi demo at the Haskell Symposium, and the video (recorded "guerrilla style") is available! (It should also appear on the ACM Digital Library too, hopefully in better quality, but don't hold your breath.)"
...and the video <--- "video" hyperlinked w/ URL I gave...
Incremental parsing is also the first step toward incremental type checking :)
The post is a bit wrong, there have been incremental parsing frameworks in the past (see Tim Wagner and Susan Graham's work on Harmonia at UCB). But I've never been able to use them very well, and the problem is simple enough that cache/damage/repair is good enough (actually for type checking also).