Hi Neil, personally, I think that historical preservation of a reference approach is quite a different issue (hosting a copy of the Syb page at haskell.org, and a copy of the library on hackage, would be a start), which might also need a maintainer at some point, but Syb1+2 is part of base right now, and available from Ralf's old pages. So far, it does seem as if most of the items I'm interested in can be done on top of Data.Generics, simply bypassing the higher-level API and providing an alternative, but very close, higher-level API on top of the same low-level API (though I sometimes wonder whether gfoldl's second parameter should be generic rather than polymorphic). But what it comes down to is that I'd like to start with a working, well supported approach (Syb 1+2), and see whether we can close any of the known gaps without starting from scratch with yet-another- generics-library. And if that means morphing what is there into something even more useful, by taking inspirations from Syb 4 or Uniplate or .., I'm all for it, as long as it is a continuous evolution supported by evidence, not a heart-liver-and-lung transplant supported by hope.
1) Speed improvements, if possible
What I'm working on are mostly more convenient access to better performance in the higher-level API (traversal schemes), reducing the need for hand-tuned traversals using the low-level API directly. The part inspired by Uniplate's PlateData seems to be working, the part about replacing nested typecases with Map lookup is currently burried in other effects.
2) API tweaks, maybe a few extra functions (universe equivalent would be nice)
It seems we've got fmap and traverse defineable in terms of Data/ Typeable, so one could derive the latter two, then get the former for free, so to speak. But should these be in some Data.Generics.Utils, or should they move into Data.Traversable, etc (which already has some default functions for defining instances of one class in terms of another)? And if you mean {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE RankNTypes #-} import Data.Generics universe :: forall a . Data a => a -> [a] universe = everything (++) ([] `mkQ` child) where child = return :: a -> [a] then we're probably just talking about better performance from naive definitions (1) again, or is anything else wrong with that definition?
3) Make it work with Hugs - I've always been surprised that SYB doesn't work with Hugs, and I don't think its that much work.
Hmm, I'm still fond of Hugs, but I haven't used it much recently, so I'd be the wrong person for that job. On casual glance, I can't even think of any Syb-essential language features that aren't supported in Hugs (apart from deriving Data/Typeable), and my old WinHugs doesn't seem to have/support a cpp, which gets in the way of just loading the code - why doesn't Syb work with Hugs? 4) Improve useability Things like 'typeOf1' not working with 'Data a => a', or 'gzipWithT' giving fun type errors unless we eta-expand its first parameter, Syb as a general test-bed for the quality of type error messages, etc. Here, I'm not thinking of immediate cure-alls, but of collecting the various issues, creating tickets and/or a Wiki page and looking for ways out, step by step. One item I haven't mentioned yet: can't we replace the gensym-based TypeRepKeys with something more systematic/standardised? I've wondered about this on previous occasions, to make TypeRepKeys more portable, but it would also be nice just to get rid of that IO tag (reminding us that the keys may change with each program run). Thanks for your confidence, but I'll probably just collect feedback here, contribute my code/docs when I've got everything together (would a separate syb-utils package be preferred, or direct changes to base?) and move on. I look forward to your comments, though, when you get out of that tent!-) Claus