- Libraries - Haskell.org

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

Delivery Notification: Delivery has been delayed
by Internet Mail Delivery 31 Aug '03

31 Aug '03

This report relates to a message you sent with the following header fields: Return-path: <libraries(a)haskell.org> Received: from ms-dienst.rz.rwth-aachen.de by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) id <0HKI00KJV9VWLK(a)ms-dienst.rz.rwth-aachen.de>; Mon, 1 Sep 2003 00:45:32 +0200 (MEST) Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HKC00EWUNSGEK(a)ms-dienst.rz.rwth-aachen.de> for michaelw(a)foldr.org; Fri, 29 Aug 2003 00:00:17 +0200 (MEST) Received: from relay.RWTH-Aachen.DE ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Fri, 29 Aug 2003 00:00:16 +0200 (MEST) Received: from poolmail.informatik.rwth-aachen.de (harry.Informatik.RWTH-Aachen.de [137.226.116.28]) by relay.rwth-aachen.de (8.12.9/8.12.7-1) with ESMTP id h7SM0FvP004828 for <michaelw(a)foldr.org>; Fri, 29 Aug 2003 00:00:15 +0200 (MEST) Received: by poolmail.informatik.rwth-aachen.de (Postfix) id 71199A8CF; Fri, 29 Aug 2003 00:00:14 +0200 (CEST) Received: from ms-dienst.rz.rwth-aachen.de (ms-1.rz.RWTH-Aachen.DE [134.130.3.130]) by poolmail.informatik.rwth-aachen.de (Postfix) with ESMTP id 63A60A8CD for <michaelw(a)pool.informatik.rwth-aachen.de>; Fri, 29 Aug 2003 00:00:14 +0200 (CEST) Received: from ue250-1 (ue250-1.rz.RWTH-Aachen.DE [134.130.3.33]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HKC00ED7NSE4I(a)ms-dienst.rz.rwth-aachen.de> for michaelw(a)pool.informatik.rwth-aachen.de (ORCPT michael.weber(a)post.rwth-aachen.de) Fri, 29 Aug 2003 00:00:15 +0200 (MEST) Received: from relay1.RWTH-Aachen.DE ([134.130.3.3]) by ue250-1 (MailMonitor for SMTP v1.2.2 ) ; Fri, 29 Aug 2003 00:00:14 +0200 (MEST) Received: from MULTIMEDIA07 ([200.24.7.180]) by relay1.rwth-aachen.de (8.12.9/8.12.7/1) with ESMTP id h7SLxaGt008614 for <michael.weber(a)post.rwth-aachen.de>; Thu, 28 Aug 2003 23:59:49 +0200 (MEST) Date: Thu, 28 Aug 2003 17:00:36 +0500 From: libraries(a)haskell.org Subject: Re: Approved To: michael.weber(a)post.rwth-aachen.de Cc: Message-id: <200308282159.h7SLxaGt008614(a)relay1.rwth-aachen.de> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/mixed; boundary="Boundary_(ID_ELsf7lXSmA4i5C80HX+MQA)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Delivered-to: michaelw(a)pool.informatik.rwth-aachen.de X-MailScanner: Found to be clean X-Spam-Status: No, hits=4.7 required=6.0 tests=INVALID_DATE,MICROSOFT_EXECUTABLE,MIME_BOUND_NEXTPART, MIME_MISSING_BOUNDARY,MISSING_MIMEOLE,NO_REAL_NAME, RAZOR2_CHECK version=2.55 X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Your message has been enqueued and undeliverable for 3 days to the following recipients: Recipient address: michaelw(a)foldr.org Reason: unable to deliver this message after 3 days Delivery attempt history for your mail: Sun, 31 Aug 2003 16:50:25 +0200 (MEST) TCP active open: Failed connect() Error: Connection refused Sun, 31 Aug 2003 08:50:25 +0200 (MEST) TCP active open: Failed connect() Error: Connection refused Sun, 31 Aug 2003 00:46:33 +0200 (MEST) TCP active open: Failed connect() Error: Connection refused Sat, 30 Aug 2003 16:42:07 +0200 (MEST) TCP active open: Failed connect() Error: Connection refused Sat, 30 Aug 2003 08:37:26 +0200 (MEST) michaelw(a)foldr.org: smtp;450 4.7.1 <michaelw(a)foldr.org>... recipient denied, because internal DNS error Sat, 30 Aug 2003 00:34:18 +0200 (MEST) michaelw(a)foldr.org: smtp;450 4.7.1 <michaelw(a)foldr.org>... recipient denied, because internal DNS error Fri, 29 Aug 2003 16:30:13 +0200 (MEST) TCP active open: Failed connect() Error: Connection refused Fri, 29 Aug 2003 12:27:30 +0200 (MEST) TCP active open: Failed connect() Error: Connection refused Fri, 29 Aug 2003 09:20:48 +0200 (MEST) TCP active open: Failed connect() Error: Connection refused Fri, 29 Aug 2003 05:18:15 +0200 (MEST) TCP active open: Failed connect() Error: Connection refused Fri, 29 Aug 2003 03:11:43 +0200 (MEST) TCP active open: Failed connect() Error: Connection refused Fri, 29 Aug 2003 01:09:26 +0200 (MEST) TCP active open: Failed connect() Error: Connection refused Fri, 29 Aug 2003 00:01:28 +0200 (MEST) TCP active open: Failed connect() Error: Connection refused The mail system will continue to try to deliver your message for an additional 1 day. Return-path: <libraries(a)haskell.org> Received: from ms-dienst.rz.rwth-aachen.de by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) id <0HKI00KJV9VWLK(a)ms-dienst.rz.rwth-aachen.de>; Mon, 1 Sep 2003 00:45:32 +0200 (MEST) Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HKC00EWUNSGEK(a)ms-dienst.rz.rwth-aachen.de> for michaelw(a)foldr.org; Fri, 29 Aug 2003 00:00:17 +0200 (MEST) Received: from relay.RWTH-Aachen.DE ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Fri, 29 Aug 2003 00:00:16 +0200 (MEST) Received: from poolmail.informatik.rwth-aachen.de (harry.Informatik.RWTH-Aachen.de [137.226.116.28]) by relay.rwth-aachen.de (8.12.9/8.12.7-1) with ESMTP id h7SM0FvP004828 for <michaelw(a)foldr.org>; Fri, 29 Aug 2003 00:00:15 +0200 (MEST) Received: by poolmail.informatik.rwth-aachen.de (Postfix) id 71199A8CF; Fri, 29 Aug 2003 00:00:14 +0200 (CEST) Received: from ms-dienst.rz.rwth-aachen.de (ms-1.rz.RWTH-Aachen.DE [134.130.3.130]) by poolmail.informatik.rwth-aachen.de (Postfix) with ESMTP id 63A60A8CD for <michaelw(a)pool.informatik.rwth-aachen.de>; Fri, 29 Aug 2003 00:00:14 +0200 (CEST) Received: from ue250-1 (ue250-1.rz.RWTH-Aachen.DE [134.130.3.33]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HKC00ED7NSE4I(a)ms-dienst.rz.rwth-aachen.de> for michaelw(a)pool.informatik.rwth-aachen.de (ORCPT michael.weber(a)post.rwth-aachen.de) Fri, 29 Aug 2003 00:00:15 +0200 (MEST) Received: from relay1.RWTH-Aachen.DE ([134.130.3.3]) by ue250-1 (MailMonitor for SMTP v1.2.2 ) ; Fri, 29 Aug 2003 00:00:14 +0200 (MEST) Received: from MULTIMEDIA07 ([200.24.7.180]) by relay1.rwth-aachen.de (8.12.9/8.12.7/1) with ESMTP id h7SLxaGt008614 for <michael.weber(a)post.rwth-aachen.de>; Thu, 28 Aug 2003 23:59:49 +0200 (MEST) Date: Thu, 28 Aug 2003 17:00:36 +0500 From: libraries(a)haskell.org Subject: Re: Approved To: michael.weber(a)post.rwth-aachen.de Cc: Message-id: <200308282159.h7SLxaGt008614(a)relay1.rwth-aachen.de> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/mixed; boundary="Boundary_(ID_ELsf7lXSmA4i5C80HX+MQA)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Delivered-to: michaelw(a)pool.informatik.rwth-aachen.de X-MailScanner: Found to be clean X-Spam-Status: No, hits=4.7 required=6.0 tests=INVALID_DATE,MICROSOFT_EXECUTABLE,MIME_BOUND_NEXTPART, MIME_MISSING_BOUNDARY,MISSING_MIMEOLE,NO_REAL_NAME, RAZOR2_CHECK version=2.55 X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) This is a multipart message in MIME format --Boundary_(ID_ELsf7lXSmA4i5C80HX+MQA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Please see the attached file for details. --Boundary_(ID_ELsf7lXSmA4i5C80HX+MQA) Content-type: Text/Plain; name=MailMonitor_report.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=MailMonitor_report.txt Client: MailMonitor for SMTP v1.2.2 The message body part has been replaced with this note. Problem description: Attachment validity check: passed. Virus identity found: W32/Sobig-F

1 0