- Libraries - Haskell.org

RE: Toward a Unified Packaging System
by Simon Peyton-Jones 11 Sep '03

11 Sep '03

| Isaac has a rather nice writeup in the Wiki: | | http://haskell.org/hawiki/LibraryInfrastructure It's a great start, but (for example) the key section (2) has "DistUtils" as a heading, which means nothing to me, and talks of python-style distutils. I'm utterly ignorant of Python. Learning from existing systems is definitely the Right Thing, and the discussion among experts can use as much terminology as is useful, but I'm still hoping ultimately for a presentation that does not assume you are already au fait with other systems. S

2 1

RE: Toward a Unified Packaging System
by Simon Marlow 11 Sep '03

11 Sep '03

> As you know, I'm dead keen to see this happen. Thank you for leading > this effort. > > What would really help me is a summary, in one place (on the web) of > what you propose, without assuming much prior knowledge. Isaac has a rather nice writeup in the Wiki: http://haskell.org/hawiki/LibraryInfrastructure Cheers, Simon

1 0

RE: Toward a Unified Packaging System
by Simon Peyton-Jones 11 Sep '03

11 Sep '03

| What would Haskell Implementations need to do to conform (at minimum): | | 1) Include Distribution.Package with your libraries | | 2) Add the packages marked "auto" to the search-path for imports | | 3) Allow a -package flag to add non-auto packages to the search-path | | | So my question to you is, would the authors of the Haskell | implementations add something like this to their systems, and help to | port the Distribution.Package library? Are there major things I'm | missing, or is there anything here which would make this overly hard | for any particular implementation? As you know, I'm dead keen to see this happen. Thank you for leading this effort. What would really help me is a summary, in one place (on the web) of what you propose, without assuming much prior knowledge. Rather than specifying the interface of Distribution.Package, I suggest starting with the desired goal: The goal is to make it possible for someone to download a package, cd to the root directory of the package, and run Setup.hs --ghc to install the package for GHC, or Setup.hs --hugs to install the package for Hugs (Maybe that's not right already. Doubtless there are other options.) >From that point, you can describe various ways in which Setup.hs might do its work: - Distribution.Package provides facilities that make it easy to write various Setup.hs's - the package is described by a data structure of type Package, by convention put in PackageDesc.hs (alongside Setup.hs) - what support is needed from the GHC/Hugs/Nhc etc to let Setup.hs do its work - what Joe Programmer would need to do to build a package. etc. Top down makes it possible for someone like me to understand why the interfaces in Disribution.Package look the way they do. Simon

1 0

Toward a Unified Packaging System
by Isaac Jones 11 Sep '03

11 Sep '03

As part of the Library Infrastructure Project [1], there is the need for a way to let the system and perhaps Haskell compilers and interpreters know about packages (libraries and other tools) which are being installed. It would be very useful, therefore, to have a unified packaging system agreed upon by the Haskell Implementors. I talked about this a bit at the Haskell Implementor's Meeting. The main features of this system would be: 1) To let the compiler / interpreter know how to use a package, whether its available by default (or whether it requires a -package flag), and where the root of its hierarchy is. 2) To store other information about a package, including stuff like its license, home page, version number, and dependencies, to be used by other tools in the "Distribution" hierarchy. 3) All information will be made available through a Haskell Module, whose proposed name is Distribution.Package. The information can be made available to non-haskell tools by way of a command-line tool, haskell-config with easily parsable output (similar to package-config [2]) though a different solution may be necessary for windows. Any thoughts? Some secondary features would be: 1) Let other tools, such as debuggers and editors, know where the source code for a module / package is. 2) When new Haskell implementations are installed, allow them to find the source code and import it into their own library tree (perhaps through other features of the L.I.P.) 3) For Haskell implementations which don't conform to the new packaging interface, implement a wrapper so that it can still utilize other important features of the Library Infrastructure Project. The information would be held in a file, such as /etc/haskell/packages.conf and ~/.haskell/packages.conf. In practice, version information would also be of importance to some of the below functions, as the system intends to allow multiple versions of a package to coexist on the system. ------------------------------------------------------------ The package data structure might look something like this (based on GHC's Package class) data PackageConfig = Package { name :: String, version :: Version, license :: License, auto :: Bool, provides :: [String] -- might indicate that this package provides functionality which other packages also provide, such as a compiler or GUI framework, and upon which other packages might depend.. [3] isDefault :: Bool, -- might indicate if this is the default compiler or GUI framework. import_dirs :: [String], source_dirs :: [String], library_dirs :: [String], hs_libraries :: [String], extra_libraries :: [String], include_dirs :: [String], c_includes :: [String], build_deps :: [String], -- build dependencies depends :: [String], -- use dependencies -- In practice, the dependency types will probably have to be a bit more complex so as to allow for version information. extra_ghc_opts :: [String], extra_cc_opts :: [String], extra_ld_opts :: [String], framework_dirs :: [String], extra_frameworks:: [String] data Version = ... data License = GPL | LGPL | BSD | ... | (OtherLicense FilePath) But perhaps we'll need to be even more flexible: some implementations might not be interested in certain fields, and others might want their own fields. It would certainly be desirable to have a flexible parser so that we can add more fields later and maintain backward compatibility. ------------------------------------------------------------ The Distribution.Package API might look like so: getSystemConfig :: IO [Package] getUserConfig :: IO [Package] addUserPackage :: Package -> IO () addSystemPackage :: Package -> IO () delUserPackage :: String -> IO () -- might need more info, like version delSystemPackage :: String -> IO () basicPackage :: Package -- provides sensible defaults checkLicense :: Package -> Bool -- Just for fun, check to see if the licences that this package uses conflicts with any of the packages it depends on ------------------------------------------------------------ The command-line tool might be invoked like so: % haskell-pkg --add-package < packageFile % haskell-package hunit c_includes # would output this list in a way that a C compiler could use directly % haskell-pkg --list-packages % haskell-pkg --list-user-packages % haskell-pkg --list-system-packages ------------------------------------------------------------ What would Haskell Implementations need to do to conform (at minimum): 1) Include Distribution.Package with your libraries 2) Add the packages marked "auto" to the search-path for imports 3) Allow a -package flag to add non-auto packages to the search-path So my question to you is, would the authors of the Haskell implementations add something like this to their systems, and help to port the Distribution.Package library? Are there major things I'm missing, or is there anything here which would make this overly hard for any particular implementation? peace, isaac Footnotes: [1] http://www.haskell.org/hawiki/LibraryInfrastructure [2] http://www.freedesktop.org/software/pkgconfig/ [3] For a library, Provides would indicate that they conform to a pretty standard interface, for an application, they would only have to be roughly equivalent.

1 0

RE: RealWorld
by Simon Peyton-Jones 08 Sep '03

08 Sep '03

I prefer IORegion myself, because the 's' parameter of the monad isn't really the state type itself; it's more like a name for the state. The real state can have a type like (State s). The 's' parameter keeps different states separate; it's not the state itself. So region is good. but i'm not going to die in the trenches for this one! Having said my piece, I'll shut up Simon | -----Original Message----- | From: Sven Panne [mailto:Sven.Panne@informatik.uni-muenchen.de] | Sent: 08 September 2003 12:28 | To: Ross Paterson | Cc: Simon Peyton-Jones; libraries(a)haskell.org | Subject: Re: RealWorld | | Ross Paterson wrote: | > On reflection, IORegion sounds a bit operational; perhaps IOState is | > better (though I see the name is used in HOpenGL for something else). [...] | | No problem here, it's just an internal module/type with a rather | ad-hoc name. | | Cheers, | S. | |

1 0

RE: RealWorld
by Simon Peyton-Jones 08 Sep '03

08 Sep '03

Would be fine with me. | -----Original Message----- | From: libraries-admin(a)haskell.org [mailto:libraries-admin@haskell.org] On Behalf Of Ross Paterson | Sent: 05 September 2003 11:08 | To: libraries(a)haskell.org | Subject: RealWorld | | Now that RealWorld, formerly an implementation trick inside GHC, has | become part of the public interface: | | stToIO :: ST RealWorld a -> IO a | | (to make stToIO sound), I think it needs a better name. The IO monad | does not in fact give you exclusive access to the world, but to a | region of the heap separate from those used by invocations of runST. | (That's not all IO does, of course, but it's the relevant part for | stToIO.) I propose IORegion. | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

3 2

RE: bracket, (un)block and MonadIO
by Simon Marlow 08 Sep '03

08 Sep '03

> On Friday 05 September 2003 1:02 pm, Keith Wansbrough wrote: > > > -- ** The @handle@ functions > > > - handle, -- :: (Exception -> IO a) -> IO a -> IO a > > > - handleJust,-- :: (Exception -> Maybe b) -> (b -> IO a) > -> IO a -> IO a > > > + handle, -- :: MonadIO m => (Exception -> m a) -> m a -> m a > > > + handleJust,-- :: (Exception -> Maybe b) -> (b -> m a) > -> m a -> m a > > > > Is the MonadIO constraint on m intentionally missing from > handleJust? > > No, it's an unfortunate omission. Thanks for pointing that out! > Corrected patch attached. This patch is still too deeply wired-in for my liking. It generalises the types of all the IO-related functions in Control.Exception. We don't intend to generalise *every* IO function over MonadIO, that's what liftIO is for. And hence, we shouldn't also generalise functions that take IO-typed arguments, since that is what liftIO' is for, and so on. By all means provide the generalised versions for convenience, but I don't believe we should generalise the originals. Cheers, Simon

1 0

RE: bracket, (un)block and MonadIO
by Simon Marlow 05 Sep '03

05 Sep '03

> See the attached patch for the details. > > This solution is maybe a bit ugly, since these methods are fairly > specific (liftIO' is needed to generalize block and unblock, and > liftIO'' is needed to generalize catchException). > > But it does allow one to use catch/bracket/etc with monads built on > top of IO with monad transformers, which is quite nice: Thanks. I think I would prefer to have the generalised versions of block/unblock/catchException separate from the IO-specific versions, and exported by one of the Control.Monad modules, to avoid breaking too much code, and to avoid wiring MonadIO in too deeply. Would you mind redoing the patch? Iavor: how do these changes sit with your redesign of the monad stuff? Cheers, Simon

4 4

RE: RealWorld
by Simon Marlow 05 Sep '03

05 Sep '03

> Now that RealWorld, formerly an implementation trick inside GHC, has > become part of the public interface: > > stToIO :: ST RealWorld a -> IO a > > (to make stToIO sound), I think it needs a better name. The IO monad > does not in fact give you exclusive access to the world, but to a > region of the heap separate from those used by invocations of runST. > (That's not all IO does, of course, but it's the relevant part for > stToIO.) I propose IORegion. Fine by me too. Cheers, Simon

1 0

RealWorld
by Ross Paterson 05 Sep '03

05 Sep '03

Now that RealWorld, formerly an implementation trick inside GHC, has become part of the public interface: stToIO :: ST RealWorld a -> IO a (to make stToIO sound), I think it needs a better name. The IO monad does not in fact give you exclusive access to the world, but to a region of the heap separate from those used by invocations of runST. (That's not all IO does, of course, but it's the relevant part for stToIO.) I propose IORegion.

1 0