* haskell-src-exts is not slow. It can parse a 769 module codebase racking up to 100k lines of code in just over a second on my machine. That's good. Also, I don't think speed of the individual file matters, for reasons I state below.
Wow, that's faster than my machine.
* Broken source is not a big issue to me. Code is written with a GHCi session on-hand; syntactic issues are the least of my worries. I realise it will be for others.
I do to, but my usual practice is to have ghci in another window, save the file, and hit :r over there. So it's distracting when the tags program spits out a bunch of syntax errors, I'm used to seeing those in ghci. And I save somewhat compulsively :)
The problem with haskell-src-exts is that it refuses to parse expressions for which it cannot reduce the operator precedence, meaning it can't parse any module that uses a freshly defined operator.
Oh right, I remember having that problem too.
The reason I don't think individual file performance matters is that the output can be cached. There's also the fact that if I modify a file, and generate tags, I'm likely editing that file presently, and I'm not likely to need jumping around which tags provides.
It's true for me too, though I like the convenience of retagging on every single save. But it's true that given incremental tags regeneration, haskell-src-exts is plenty fast too. I didn't put a lot of thought into the name, but I mostly just wanted tags I could run on every save.
Then there's the venerable hasktags, but it's buggy and the source is a mess. I fixed a bug where it doesn't actually strip comments so it makes tags to things inside comments, but then decided it would be easier to just write my own.
Hasktags is hardly buggy in my experience. The comments bug is minor. But I agree that the codebase is messy and would be better handled as Text. But again, speed on the individual basis isn't a massive issue here.
The comments thing was really big for me. It made it miss a lot of tags.
Unfortunately there appears to be a horrific problem with it, as the log below shows:
Ouch. I probably have some kind of laziness problem in there. I'll try downloading some stuff from cabal and try it on some different codebases.
I like the fast-tags codebase so it would be nice to start using it, but I hope you can test it on either a more substantial codebase or just a different codebase. Or just grab some packages from Hackage and test. Emacs support would be nice, I might add it myself if you can fix the performance explosion. Right now hasktags is OK for me. I won't be hacking on it in the future for more features because…
Will do. I also realized 'x, y :: ' type stuff doesn't work. And it might be nice to support internal definitions and use vim's "static tag" feature.
While we're on the topic I think haskell-src-exts is worth investing time in, as it has semantic knowledge about our code. I am trying to work on it so that it can preserve comments and output them, so that we can start using it to pretty print our code, refactor our code, etc. It could also be patched to handle operators as Operators [Exp] rather than OpApp x (OpApp y), etc. I think.
Oh I agree haskell-src-exts is great and I love it. I used it for
fix-imports. It does support comments, but dealing with them was a
pain because they just have line numbers and you have to do some work
to figure out which bit of source they are "attached" to. Part of the
problem is, of course, that "attached" is a fuzzy concept, but there
could definitely be some tools to make it easier.
Actually, if haskell-src-exts had a lenient parsing mode then it would
be easier to use and less buggy than a hand-written thing.
On Sun, Apr 1, 2012 at 1:44 PM, Levent Erkok
Chris: You might be experiencing this issue: http://hackage.haskell.org/trac/ghc/ticket/5783
I'm guessing not, since he was using 0.0.2, which has the version constraint. And his symptoms are different.