naming of directories for the new libraries
The Hugs counterpart of a package is a directory that can be put in the search path. Currently I'm using two: libraries - corresponding to the new hierarchical libraries packages base, haskell98 and haskell-src oldlib - a flat directory corresponding to hslibs and lib/exts Compilers don't like huge packages, but that doesn't apply to an interpreter. Still, maybe we'll need more packages in the future, so to allow for future expansion I'm thinking of renaming these libraries -> libraries/core oldlib -> libraries/compat More to type in -P though (maybe put them in lib?)
Compilers don't like huge packages, but that doesn't apply to an interpreter. Still, maybe we'll need more packages in the future, so to allow for future expansion I'm thinking of renaming these
libraries -> libraries/core oldlib -> libraries/compat
More to type in -P though (maybe put them in lib?)
These names sound reasonable. The name 'base' occurs to me instead of 'core' but either is good. I'm tempted to suggest 'deprecated' instead of 'compat' but that's probably going a bit far. Using 'lib' is probably the rigth thing to do: it keeps the tree simpler to maintain, people are used to looking in lib and, as you say, it's less to type. btw Should the files in hugs98/libraries/Hugs which come from CVS be moving into the libraries repository just as there's a bunch of GHC specific stuff in libraries/GHC? (That is, should this not be a subdirectory of hugs98.) This is probably what you were talking about when you said there was a little cleanup needed which could wait until after release... -- Alastair
Alastair Reid
Compilers don't like huge packages, but that doesn't apply to an interpreter. Still, maybe we'll need more packages in the future, so to allow for future expansion I'm thinking of renaming these
libraries -> libraries/core oldlib -> libraries/compat
More to type in -P though (maybe put them in lib?)
These names sound reasonable. The name 'base' occurs to me instead of 'core' but either is good.
I just wanted to comment on the naming. It would be good if "packages", (whatever that means for the different Haskell systems) have the same names for all systems, in the same way that the modules they contain have the same names and interfaces. Thus, since "base" has already been chosen in the fptools/libraries CVS repository, that should be what Hugs and nhc98 call it as well. Likewise for "network", "haskell-src", "ObjectIO", "OpenGL", etc, if and when they get included for each compiler/interpreter. Out of interest, I recently released HaXml as a hierarchical library "package" for ghc and nhc98. Obviously I'd like it to work with Hugs as well. What would be the "official" way for a third-party package like mine to integrate itself into a pre-existing Hugs installation? Regards, Malcolm
I just wanted to comment on the naming.
Thanks. This sounds like good advice.
Out of interest, I recently released HaXml as a hierarchical library "package" for ghc and nhc98. Obviously I'd like it to work with Hugs as well. What would be the "official" way for a third-party package like mine to integrate itself into a pre-existing Hugs installation?
I don't know about 'official' but the way I'd do it is: - unpack the module somewhere ($prefix/lib/hugs/lib/$pkgname would be a fine choice but other places are good too) - run hugs +G on any ffiable libraries - add -P$prefix/lib/hugs/lib/$pkgname: (or whatever) to HUGSFLAGS Obviously, the last step isn't very convenient to script. There's various ways this could be fixed (wrapper scripts which generate search paths from a list of installed packages and then invoke Hugs, adding package support directly to Hugs, using the search path as a list of directories that might contain _packages_ (instead of as a list of directories that might contain _modules_)) but I don't think Hugs has any at the moment. -- Alastair
On Fri, Aug 16, 2002 at 04:06:19PM +0100, Alastair Reid wrote:
These names sound reasonable. The name 'base' occurs to me instead of 'core' but either is good.
It's not base, it's base + haskell98 + haskell-src (+ network later), i.e. what the documentation calls the "Haskell Core Libraries". An alternative would be a separate directory for each of these, at the cost of a long path. But maybe a packages directory doesn't make sense until Hugs has a bit of package support.
btw Should the files in hugs98/libraries/Hugs which come from CVS be moving into the libraries repository just as there's a bunch of GHC specific stuff in libraries/GHC? (That is, should this not be a subdirectory of hugs98.)
I thought of that, but these modules are fairly closely tied to the Hugs sources, mainly via Hugs primitives.
This is probably what you were talking about when you said there was a little cleanup needed which could wait until after release...
That was more eliminating code duplication, and possibly using some form of your prelude-splitting patch to remove special cases.
It's not base, it's base + haskell98 + haskell-src (+ network later), i.e. what the documentation calls the "Haskell Core Libraries". An alternative would be a separate directory for each of these, at the cost of a long path. But maybe a packages directory doesn't make sense until Hugs has a bit of package support.
Sounds good. I guess once we have proper packages, people won't have to tweak the search paths manually anyway so a change won't affect them.
btw Should the files in hugs98/libraries/Hugs which come from CVS be moving into the libraries repository just as there's a bunch of GHC specific stuff in libraries/GHC? (That is, should this not be a subdirectory of hugs98.)
I thought of that, but these modules are fairly closely tied to the Hugs sources, mainly via Hugs primitives.
The libraries/GHC code is quite tightly tied to GHC too. What I see happening is a gradual shift to Hugs consisting of the Hugs interpreter (C + Makefiles) in the hugs98 directory plus a bunch of jointly maintained library code (Haskell plus C/FFI) in the libraries directory - some of which is Hugs-specific and some of which is shared with GHC and NHC. We don't have to buy into this now but I think it's the way we're heading. [Hmmm, I seem to remember CVS having a way to formalize this sort of cross-hierarchial relationship.] -- Alastair
participants (3)
-
Alastair Reid -
Malcolm Wallace -
Ross Paterson