According to the current hierarchy document[1] we have these libraries under Graphics.X11.Xlib. Perhaps these names would be correct:
Graphics.X11.Xlib Graphics.X11.Xlib.Types Graphics.X11.X1ib.StdDIS
The reason for separating Xlib into its own hierarchy is that there are other APIs under X11 (Xt, Xaw, Xmu).
That makes sense except that I didn't tell you enough about Types and StdDIS. Types contains generic X11 types (which would be used by Xt, Xaw, etc). StdDIS contains generic GreenCard definitions and would also be used by Xt, etc. So I see things developing as follows:
Graphics.X11 -- reexports all children except StdDIS Graphics.X11.StdDIS -- should be shared by all GC'd files Graphics.X11.Types -- shared by all X11 impls Graphics.X11.Xlib Graphics.X11.Xt Graphics.X11.Xaw Graphics.X11.Xmu
[StdDIS is just a copy of the file included in GreenCard distributions and would go away if we were to do the sensible thing and have a single StdDIS somewhere in the libraries tree.]
Ok for Graphics.X11.Types. For StdDIS, if it is shared by all greencard-generated source, then it probably should be something like Greencard.StdDIS and kept in a separate greencard package. For now, putting it in Graphics.X11.StdDIS (and not advertising its existence) should be fine.
Win32 is currently listed as being under System.Win32. However, since we've just put Dotnet at the top of the hierarchy, and Win32 contains a range of both systems and graphics stuff, I'd be happy for it to be at the top of the hierarchy too.
I think I'd prefer both to be under System.
For Dotnet at least, there's a whole hierarchy that lives under it that mirrors the .NET class hierarchy. System.Dotnet.System.Xml would be a bit of a mouthful, for example. But also these libraries don't fall into any single category in the Haskell hierarchy, so there's no reason we should place them under System any more than Graphics, for example. System.Posix is different: it only deals with system interaction (although the network bits of System.Posix really live under Network, so it's not a clean break).
HGL is assigned Graphics.HGL, which seems like the right thing.
Ok, I'll put it there.
Or Graphics.Rendering.HGL as Malcolm suggested (actually this is probably more accurate).
The NHC folks seem to be using their own Makefiles, called Makefile.nhc98.
I'll probably do the same.
Hmmm, I wonder if the existing scriptMakefile used by Hugs to convert and compile the libraries should be moved into libraries/base ?
By all means...
I gather that the Win32 library is needed for windows version of GHC so it's a bit moer of an issue there...
It's distibuted with the Win32 GHC, but isn't needed by it (AFAIK). Cheers, Simon
Hi all,
Graphics.X11.Xlib Graphics.X11.Xlib.Types Graphics.X11.X1ib.StdDIS
Last time I checked, GreenCard choked on hierarchical module names, forcing me to use names like Graphics_X11_Xlib_StdDIS to make it that there are no conflicts with other StdDIS's. Has this been fixed? /Henrik -- Henrik Nilsson Yale University Department of Computer Science nilsson@cs.yale.edu
For StdDIS, if it is shared by all greencard-generated source, then it probably should be something like Greencard.StdDIS and kept in a separate greencard package.
Only minor problem with making it a separate package is that the primary purpose of StdDIS is to provide the DISs which tell GreenCard how to marshall ints, floats, ptrs, etc. - the Haskell code it contains is a fairly minor part. So, if it is to be usable from other packages, the other packages need to be able to read the raw source code of StdDIS not just access a .hi and .o file. I'm not sure how will this fits with the package story.
For now, putting it in Graphics.X11.StdDIS (and not advertising its existence) should be fine.
I'll do that.
HGL is assigned Graphics.HGL, which seems like the right thing.
Ok, I'll put it there.
Or Graphics.Rendering.HGL as Malcolm suggested (actually this is probably more accurate).
To me, the word 'Rendering' suggests that it can (only) do output (drawing graphics) but HGL also does input (reading keyboard and mouse events). So I think Graphics.HGL is more accurate. But the same argument surely applies to OpenGL too (???) so maybe I'm reading too much into 'Rendering'? -- Alastair
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 A variant on this is to recognize that this is the only file in the library and drop the trailing /StdDIS: Foreign.GreenCard.hs GreenCard.hs Apps.GreenCard.hs <SomeOtherPrefix>.GreenCard.hs Any opinions? (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.) [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.] -- Alastair Alastair Reid mentioned:
[...] Graphics.X11.StdDIS -- should be shared by all GC'd files [...] [StdDIS is just a copy of the file included in GreenCard distributions and would go away if we were to do the sensible thing and have a single StdDIS somewhere in the libraries tree.]
On Wednesday 02 April 2003 2:48 pm, Simon Marlow wrote:
For StdDIS, if it is shared by all greencard-generated source, then it probably should be something like Greencard.StdDIS and kept in a separate greencard package. For now, putting it in Graphics.X11.StdDIS (and not advertising its existence) should be fine.
Alastair Reid
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.
Foreign.GreenCard.StdDIS.hs GreenCard.StdDIS.hs Apps.GreenCard.StdDIS.hs <SomeOtherPrefix>.GreenCard.StdDIS.hs
A variant on this is to recognize that this is the only file in the library and drop the trailing /StdDIS:
As another point of reference, the version of GreenCard that is distributed with nhc98 has never used the name StdDIS. It originally used 'import GreenCard', which has recently become 'import NHC.GreenCard' with the advent of the hierarchical libs. For this reason, I would support the following suggestion:
Foreign.GreenCard.hs
for distribution with the main Hugs/ghc version of GreenCard. Regards, Malcolm
As another point of reference, the version of GreenCard that is distributed with nhc98 has never used the name StdDIS. It originally used 'import GreenCard', which has recently become 'import NHC.GreenCard' with the advent of the hierarchical libs.
This is a bit of a side-issue but... I thought the current CVS copy of GreenCard would work for NHC using the ffi target. Is there a fundamental problem or is it the lack of the extensions provided in the nhc version?
For this reason, I would support the following suggestion: Foreign.GreenCard.hs
Ok, I'll go with that. [Your mail comes just as I was contemplating a giant commit which, I think, finishes off the task of updating GreenCard.] -- Alastair
Alastair Reid
This is a bit of a side-issue but... I thought the current CVS copy of GreenCard would work for NHC using the ffi target.
Yes, I would be surprised if the FFI target of the latest GreenCard did not work with nhc98 (although I haven't specifically tested it).
Is there a fundamental problem or is it the lack of the extensions provided in the nhc version?
There are two reasons why the nhc98 distribution contains a separate version of GreenCard. 1 Many of the standard libraries in nhc98 are coded using the syntax extensions to GreenCard that were agreed way back in 1997, but which somehow never got incorporated back into the main CVS. It would be a lot of pointless work to re-code them now. 2 Because building the libraries depends on having GreenCard present, it is easier to distribute GC with the compiler than to require the user to install GC separately. Regards, Malcolm
participants (4)
-
Alastair Reid -
Henrik Nilsson -
Malcolm Wallace -
Simon Marlow