[Hs-Generics] Re: Owning SYB

[Claus Reinke]

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