When I got back to work on putting an HGL release together, I realized that I'd have to do a fresh release of GreenCard first since it has a bunch of updates to work with hierarchial names, ffi, etc. The GreenCard distrib contains what ought to be the master copy of the StdDIS.{gc,hs} so I figure it ought to be made a proper library package, put in the hierarchial library namespace, etc. Obvious places to put it in the library hierarchy are:
Foreign.GreenCard.StdDIS.hs GreenCard.StdDIS.hs Apps.GreenCard.StdDIS.hs <SomeOtherPrefix>.GreenCard.StdDIS.hs
There is reasonable justification for each of these - I don't have any strong preferences. Malcolm prefers Foreign.GreenCard.hs; that's fine by me.
(btw it seems like we might see more apps with support libraries -especially if the app generates Haskell code- so this may be an instance of a more general problem.)
FWIW, in Happy and Alex I just copy some boilerplate code directly into the generated Haskell to avoid this problem. The boilerplate isn't baked into the Happy or Alex binary, it's installed as a separate file.
[btw GreenCard raises an additional issue for any library building/ packaging infrastructure. If you want to use GreenCard, you need StdDIS.gc and (the makefile which invokes) GreenCard needs to know where to find it. So we need a standard place for it to live or a way to locate it once installed.]
We've solved this problem several times (GHC, hsc2hs, Happy, Alex, Haddock). The solution I normally use for Unix systems is to have a small script which invokes the main binary passing it a flag which indicates the location of its auxiliary files (usually something like /usr/local/lib/happy). You can build a location-independent binary package which just fiddles with this script at install time. On Windows, it's rather easier because a binary can get at its own filesystem location at runtime. This all assumes the user normally wants the standard StdDIS.gc and won't want to fiddle with it, I guess. Cheers, Simon