- Libraries - Haskell.org

180 Contextual Advertising
by autumnb＠180Solutions.com 03 Oct '03

03 Oct '03

Hi, my name is Autumn Bryan and I am a Sales Assistant at 180Solutions, Inc. I noticed that you list your site www.haskell.org/ on the Overture search engine under the search term 'get green card'. I am writing to you to announce the launch of the new 180Solutions Visitor Management System - which allows you to get similar traffic to that of Overture, but for considerably lower prices. Even as low as $.015 (one and a half cents) per targeted visitor. We have over 21 million users of our n-CASE Comparison Shopping Engine - using our system will allow you to target these 21 million users at the moment that they are looking for your product or service. Our promise to you is that our traffic will make you money - hundreds of our customers have already discovered the fantastic return on investment our system provides. In addition, as an introductory offer we are currently offering a credit of 15% of your initial deposit. Whatever amount you initially put into your account, we will give you 15% more at no charge. Absolutely no tricks, no gimmicks - we just want you to try our service because we are confident that you will love what we have to offer. To take advantage of our 15% free offer, simply follow these four steps: 1. Follow this link: http://www.180solutions.com/Advertise/AdvertiserSignup.aspx?ref=adb30 2. Sign-up on our site 3. Deposit at least $100 into your account 4. Watch as you begin receiving highly targeted and extremely cost effective traffic to your site (Please allow up to three business days for your account to reflect the additional 15% credit.) We work with hundreds of online advertisers that receive a better Return On Investment with us than with any other online marketing source. I look forward to having you as a customer, please let me know if there is anything I can do personally to help make that happen. Regards, Autumn Bryan ------------------------ Autumn Bryan 180Solutions Inc autumnb(a)180Solutions.com W (425) 522-1135 F (425) 522-1199 www.180Solutions.com If you are interested in even more detailed information about us, please read on, or visit our site at: http://www.180solutions.com/?ref=adb30 We have over 21,000,000 users that have our n-CASE Comparison Shopping Software on their computers and we continue to grow by over 1.5 million users every month. Our n-CASE software is a Comparison Alternative Shopping Engine, which users install so that they can receive shopping assistance and targeted advertising messages based on what and where they are surfing online. Here are a few examples of campaigns we are currently running: 1.) When any of our users are online and type in "sales rep", "secretary" or "data entry" for example, we deliver our user to the advertisers web site with job offers directly related to the job they just typed in. 2.) When any of our users type in "running shoes", "Nike shoes", "Adidas" we deliver that user directly to the appropriate product page for our advertiser showing what they have in stock related to the users search. By delivering our advertisers web page directly to our user, it simply becomes an extension of their online search and since we aren't trying to have the user click on an advertisement, many simply proceed with their product search within our advertisers website and related products. If you expect to spend more than $5,000 per month with us, please feel free to contact me and I will connect you with one of our large account managers in order to help optimize your traffic. I look forward to having you as a customer, please let me know if there is anything I can do personally to help make that happen. Regards, Autumn Bryan To remove yourself from our email process, please click on the following link: http://www.180solutions.com/about/optout.aspx?email=libraries@haskell.org

1 0

Pre-Call for Contributions -- HC&A Report (November 2003 edition)
by C.Reinke 02 Oct '03

02 Oct '03

[apologies for multiple copies - experience has shown that not all Haskellers can be reached via the main Haskell list anymore] An entry for your diaries (no other action required right now): ------------------------------Pre-Call-------------------------------- Your contributions to the November 2003 edition of the Haskell Communities & Activities Report will be invited soon. http://www.haskell.org/communities/ Submissions are welcome between 20th and 31st of October ---------------------------------------------------------------------- The real Call for Contributions will follow closer to the submission window, in about two weeks. This is just an early warning. You will need to plan about 15 minutes for composing your contribution, which would be a brief, ASCII-format, description of your Haskell activities (see earlier editions for plenty of examples). Cheers, Claus (current editor of HC&A Reports)

1 0

RE: FW: Library Infrastructure Proposal & Home Page
by Simon Peyton-Jones 01 Oct '03

01 Oct '03

| > Consider how seemingly simple the current Haskell module system is. | > Yet dealing with the full implications of qualified imports, | > renamings, | > and hidings turned out to be pretty non-trivial when we implementors | > eventually started exercising all the corner cases. I know for a | > fact that Hugs and nhc98 still contain bugs in this area, and the | > subject even merited a Haskell Workshop paper in 2002! Yes, this stuff was trickier than it looked, but it really is orthogonal to the packages proposal, I think. I don't think there are going to be problems here. | > I think it would almost be possible to substitute "top-level name in | > the library hierarchy". That is, instead of uniquely identifying a | > Haskell entity as the triple (gtkhs-0.5, Gtk.Window, widget), I think | > one could get away with the pair (GtkHS_0_5.Gtk.Window, widget) where | > the top-level hierarchy name is derived in some standard (if ugly) | > way from your package name. | | This also occurred to me. But there's a reason for having a two-tiered | system: | | The package namespace is for distribution, dependencies, and | versioning, whereas the module hierarchy is for organising modules | by functionality. Another important aspect is that one does not want to embed version names in your Haskell source code import GTK-1.7.Graphics.UI because that makes it hard to upgrade. The same source code would compile equally well with GTK-1.8 I was talking to Erik Meijer today about the proposal, and it turns out to be remarkably similar to the Common Language Runtime story (except that they call a package an "assembly"). When compiling one says csc /r:foo /r:baz Source.cs where the /r flags are like -package; they bring into scope the exports of assemblies foo and baz. Every assembly has a globally unique name (its "strong name"), rather like our proposed package name. There's no provision for installing foo and baz so they are available without /r flags. There isn't a mechanism yet for grafting packages into different places, but there should be (else you are stuck if foo and baz both define the same namespace). At least some of this is described in Erik's recent CACM paper "What's in a name", which I have not yet read. Simon

1 0

RE: FW: Library Infrastructure Proposal & Home Page
by Simon Marlow 30 Sep '03

30 Sep '03

Malcolm Wallace writes: > "Simon Peyton-Jones" <simonpj(a)microsoft.com> writes: > > > I'd like to be confident that the package-description proposals that > > Simon and I have put out isn't incompatible in some way with NHC. > > I have been thinking about your proposal for packages, and although > there are many aspects of it that I like, and it isn't incompatible > with nhc98 as such, my gut feeling is that one particular aspect > of it is actually a very large semantic change/addition, and would > probably involve a significant amount of work to implement. I mean > this change: > > An entity in a Haskell program was previously uniquely identified > by its (module name, identifier) pair, where the module name is the > module in which the entity is defined. This now becomes a triple: > (package name, relative module name, identifier) > > Consider how seemingly simple the current Haskell module system is. > Yet dealing with the full implications of qualified imports, > renamings, > and hidings turned out to be pretty non-trivial when we implementors > eventually started exercising all the corner cases. I know for a > fact that Hugs and nhc98 still contain bugs in this area, and the > subject even merited a Haskell Workshop paper in 2002! FWIW, I agree. This has been troubling me for some time, and I think this is the reason that the packages proposal hasn't been greeted with widespread enthusiasm, despite Simon's & my attempts to simplify it. > My feeling is that the latter might apply. For instance, where in > your proposal you have chosen the new concept of "package name", > I think it would almost be possible to substitute "top-level name in > the library hierarchy". That is, instead of uniquely identifying a > Haskell entity as the triple (gtkhs-0.5, Gtk.Window, widget), I think > one could get away with the pair (GtkHS_0_5.Gtk.Window, widget) where > the top-level hierarchy name is derived in some standard (if ugly) > way from your package name. This also occurred to me. But there's a reason for having a two-tiered system: The package namespace is for distribution, dependencies, and versioning, whereas the module hierarchy is for organising modules by functionality. We long ago decided that the module hierarchy should be used for organising by functionality only. It doesn't seem right to start using it for the meta-properties of libraries too. (I guess I'm prepared to be persuaded otherwise here - there's the argument that having both namespaces can be confusing and is potentially redundant). Certainly the dependencies of a library are an essential part of the library itself, so arguably they should be present in the source (including version information), however they are also required by the packaging/building/distribution infrastructre, so keeping them separate is likely to be more convenient. Having said all this, the subject of grafting is orthogonal to whether we have a separate namespace for rank-2 modules. I consider the facilities that packages give us (versioning, unambiguous dependencies etc.) rather more important than grafting. Grafting essentially gives you a way for both source code and binary code to be independent of its absolute location in the module hierarchy. It would probably be enough to have a mechanism whereby only source code is independent of its absolute location. Ideas for relative module names have been floated before - perhaps someone would like to make a concrete proposal? Cheers, Simon

1 0

FW: FW: Library Infrastructure Proposal & Home Page
by Simon Peyton-Jones 29 Sep '03

29 Sep '03

Comments from Malcolm Wallace on the packages proposal -----Original Message----- From: Malcolm Wallace [mailto:Malcolm.Wallace@cs.york.ac.uk] Sent: 29 September 2003 04:23 To: Simon Peyton-Jones Cc: Colin.Runciman(a)cs.york.ac.uk Subject: Re: FW: Library Infrastructure Proposal & Home Page "Simon Peyton-Jones" <simonpj(a)microsoft.com> writes: > I'd like to be confident that the package-description proposals that > Simon and I have put out isn't incompatible in some way with NHC. I have been thinking about your proposal for packages, and although there are many aspects of it that I like, and it isn't incompatible with nhc98 as such, my gut feeling is that one particular aspect of it is actually a very large semantic change/addition, and would probably involve a significant amount of work to implement. I mean this change: An entity in a Haskell program was previously uniquely identified by its (module name, identifier) pair, where the module name is the module in which the entity is defined. This now becomes a triple: (package name, relative module name, identifier) Consider how seemingly simple the current Haskell module system is. Yet dealing with the full implications of qualified imports, renamings, and hidings turned out to be pretty non-trivial when we implementors eventually started exercising all the corner cases. I know for a fact that Hugs and nhc98 still contain bugs in this area, and the subject even merited a Haskell Workshop paper in 2002! The newly proposed package system seems to be a mechanism that does a similar job to the existing module system, but at one level up. Instead of managing the /value/ namespace, It brings whole /modules/ into scope, and allows qualification, renamings, and hidings at the module layer. In other words, it is a rank-2 module system. I'm not confident that it will be any easier to implement, nor analytically tractable, than the current first-order module system. Should we be looking for some generalisation towards rank-n module aggregation? Or conversely, can we show that rank-2 modules (packages) can always be re-expressed (albeit unpleasantly) by simpler rank-1 modules? My feeling is that the latter might apply. For instance, where in your proposal you have chosen the new concept of "package name", I think it would almost be possible to substitute "top-level name in the library hierarchy". That is, instead of uniquely identifying a Haskell entity as the triple (gtkhs-0.5, Gtk.Window, widget), I think one could get away with the pair (GtkHS_0_5.Gtk.Window, widget) where the top-level hierarchy name is derived in some standard (if ugly) way from your package name. With this simple modification, it becomes possible to implement package "grafting" using solely the current module system. e.g. a wrapper module like module Graphics.UI.Gtk.Window (module GtkHS_0_5.Gtk.Window) where import GtkHS_0_5.Gtk.Window could be automatically generated for each grafting point. The only clever part of the package system would be to manage these auto-coded stubs, a far easier task than implementing rank-2 modules. (For instance a clever compiler could choose to generate "virtual" grafting module stubs on-demand, with no real existence in the filesystem, whilst a simpler compiler might just store them as real files.) > Closely related are Isaacs proposals re packaging and distribution > (below). I'm not sure there's been any NHC input into that discussion > so far, and again I'd like to be sure that we don't accidentally make > things hard for NHC. Issac has been in private contact a number of times w.r.t. his proposal. I don't see any particular nhc98-related problems with his distribution and management mechanisms. Of course it is implementation work that I may not have sufficient spare time to keep up with, but I don't foresee any in-principle difficulties ahead there. Regards, Malcolm

1 0

Seeking Partnership
by David Kalon 26 Sep '03

26 Sep '03

David Kalon. reply to : Davidkalon24(a)netscape.net Attention: Sir/Madam REQUEST FOR ASSISTANCE IN A FINANCIAL TRANSACTION I am interested in your partnership in business dealing. This business proposal I wish to intimate you with is of mutual benefit and it?s success is entirely based on mutual trust, cooperation and a high level of confidentiality as regard this transaction. I am representing the board of the contract award and monitoring committe of the Zambian Ministry of Mining and Resources. I am seeking your assistance to enable me transfer the sum of US$35,500,000.00 (Thirty-five Million, Five Hundred Thousand United States Dollars) into your private/company account. The fund came about as a result of a contract awarded and executed for and on behalf of my Ministry. The contract was supposed to be awarded to two foreign contractors to the tune of US$180,000,000.00 (One hundred and Eighty Million United States Dollars). But in the course of negotiation, the contract was awarded to a Bulgarian contractor at the cost of US$144,500,000.00 (One hundred and Forty-four Million, Five Hundred Thousand United States Dollars) to my benefit unknown to the contractor. This contract has been satisfactorily executed and inspected as the Bulgarian firm is presently securing payment from my Ministry, where our Board is in-charge of all foreign contract payment approval. As a civil servant still in active government service, I am forbidden by law to operate an account outside the shores of Zambia. Hence this message to you seeking your assistance so as to enable me present your private/company account details as a beneficiary of contractual claims alongside that of the Bulgarian contractor, to enable me transfer the difference of US$35,500,000.00 (Thirty-five Million, Five Hundred Thousand United States Dollars) into your provided account. On actualisation, the fund will be disbursed as stated below. 1. 20% of the fund will be for you as beneficiary 2. 80% of the fund will be for Us. All logistics are in place and all modalities worked out for a smooth actualisation of the transaction within the next few working days of commencement. For further details as to the workability of this transaction,please reach me as soon as possible for further clarification. Thank you and God bless as I await your urgent response. Yours Sincerely, David Kalon.

1 0

RE: Library Infrastructure Proposal & Home Page
by Simon Marlow 26 Sep '03

26 Sep '03

> This is true for the FreeBSD base system, but it is > recommended nowadays > to use sysutils/portupgrade for managing ports. With > portupgrade you can > simply do `portupgrade -rf changed_pkg` to recompile all packages > depending on the changed one. The only reason why portupgrade is not > part of the base system is that it is written in ruby and we are not > willing to include ruby in the base. Heh, I've been using portupgrade for a while but managed to miss that. I usually use it in '-Rr' mode. <rant> Nevetheless, this behaviour ought to be the default. I strongly believe in this principle: Using the standard package tools on a system, in their default configuration, it should be impossible to end up with an inconsistent set of installed packages. Sadly, on FreeBSD and Gentoo this is all too easy. FreeBSD even lets you install several different versions of a package on top of each other - so that when you delete one of them, it deletes some the files belonging to the other version too (only some, because it does the md5 checksum thing). This drives me nuts. At least Gentoo is better in this regard. And the portupgrade scripts try to work around the problems with the FreeBSD ports system by looking for inconsistencies in the database and applying heuristics to try to figure out how they should be fixed. This is crazy - it should be impossible to get the inconsistencies in the first place. </rant> Cheers, Simon

2 1

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

26 Sep '03

| The reason for having an MRef class was that there were two reference | types. If there's only one, but parameterized by region, you might as | well parameterize on the region instead, describing a class of monads | that contain a heap region: That sounds plausible. I certainly don't object to the change. Simon

1 0

Library Infrastructure Proposal & Home Page
by Isaac Jones 25 Sep '03

25 Sep '03

Followups to libraries(a)haskell.org please. Greetings, After many rounds of email and discussion, some wiki work, and discussion at the HIM, I've finally put together a proposal for the Library Infrastructure Project. I've inserted the introduction below. The draft proposal itself is available in a variety of formats. I've also started a web page for the project under the haskell.org site: http://www.haskell.org/libraryInfrastructure/ Please let me know if there's anything that needs to be added, if anything is confusing, etc. Comments and questions are welcome by email or on the libraries(a)haskell.org mailing list. peace, isaac ps. I expect to be moving a lot of stuff off of the wiki page since it is duplicated here. ------------------------------------------------------------ Library Infrastructure Project Proposal The Library Infrastructure Project is an effort to provide a framework for developers to more effectively contribute their software to the Haskell community. The Haskell Implementations[1] come included with a good set of standard libraries, but this set is constantly growing and is maintained centrally. This model does not scale up well, and as Haskell grows in acceptance, the quality and quantity of available libraries is becoming a major issue. There are a wide variety of Haskell Implementations (both compilers and interpreters), each of which target a variety of hardware architectures and operating systems. There are also a number of different groups and individuals providing libraries, and these libraries depend upon each other and they depend upon external systems such as Java or GTK. It can be very difficult for an end user to manage these dependencies and build all the necessary software at the correct version numbers on their platform: there is currently no generic build system to abstract away differences between Haskell Implementations and operating systems [2]. The Library Infrastructure Project seeks to provide some relief to this situation by building tools to assist developers, end users, and operating system distributers. This is a draft proposal. If you have comments, please email Isaac Jones. The latest version of this document should be available in a variety of formats from the Library Infrastructure Project home page. _________________________________________________________ Table of Contents 1. High-Level Overview 2. Issues Facing Developers 2.1. Issues Facing Packagers 2.2. Why We Should Solve This 3. A Solution for Haskell in Haskell 3.1. The Module Design 3.2. But Why Should We Use Haskell? 3.3. Setup.lhs Command-Line Interface 3.4. An Example Setup.lhs Script 4. Distribution Module 4.1. Distribution.Build 4.2. Distribution.Install 4.3. Distribution.Package 4.3.1. PackageConfig Data Structure 4.4. haskell-config Command-line interface 4.5. haskell-pkg? 4.6. Distribution.Config 5. Use Cases 6. Means of Distribution and Layered Tools 7. Development Plan A. Related Systems A.1. Debian A.2. Python Distutils A.3. CPAN and Boost A.4. FreeBSD's Ports System A.5. The XEmacs Packaging System A.6. Make-Based Systems A.7. hmake 1. High-Level Overview On a high level, we say that we want the system to help the user to install packages (whether they be libraries or applications) and their dependencies. To accomplish this, we propose a system similar to Python's Distutils (Section A.2) where each Haskell tool is distributed with a script (Section 3.4) which has a standard command-line interface. This script will provide a familiar user interface (Section 3.3) for compiling, installing, and removing packages and their dependencies. For instance, to install the HUnit package, the user might download the source code from the web site, change into the HUnit directory, and type ./Setup.lhs install default, which would build and install the HUnit package for the default compiler. Similarly, he might type ./Setup.lhs install nhc to install the package for NHC. Other tasks might be necessary to make the package known to the system, such as registering it with the Haskell Implementation of interest (Section 4.3). Such tasks would also be performed by this Setup program. FULL TEXT AT: http://www.haskell.org/libraryInfrastructure/proposal/index.html

4 5

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

25 Sep '03

| -----Original Message----- | From: Ross Paterson [mailto:ross@soi.city.ac.uk] | Sent: 18 September 2003 10:20 | To: Simon Peyton-Jones | Cc: Alastair Reid; Simon Marlow; libraries(a)haskell.org | Subject: Re: RealWorld | | On Thu, Sep 18, 2003 at 08:56:40AM +0100, Simon Peyton-Jones wrote: | > Is the proposal that the library design exposes to the programmer the | > following type synonyms: | > | > type IO a = ST IORegion a | > type IORef a = STRef IORegion a | | The proposal is to expose | | type IORef = STRef IORegion | type IOArray = STArray IORegion | type IOUArray = STUArray IORegion | | (modulo the name of IORegion) but to keep IO opaque. I think that while | IO includes state, it is not itself a state monad (because the "state" | there can be changed by other agents at the same time). Aha. I hadn't realised that you want to expose IORef as an STRef, but not the IO monad itself. I certainly don't object to that, but I'm not sure of all the implications. For example, at the moment one could have class MRef m r | m -> r, r -> m where new :: a -> m (r a) read :: r a -> m a write :: r a -> a -> m () instance MRef IO IORef where ... instance MRef (ST s) (STRef s) where ... I don't think that'll be legal if IORef = STRef IORegion, because the "r->m" dependency becomes ambiguous. So we'd have to lose the "r->m" dependency. Maybe that's ok. (I don't think MRef currently exists in the libraries.) But it's an example of a consequence of the choice you suggest. Simon | | > I think it is sound to do so. The advantage would be that newIORef and | > newSTRef would be the same (newRef, perhaps); ditto readRef, writeRef | > etc. | | If IO is opaque, then we have | | newIORef = stToIO . newSTRef | | etc. It's not quite as generic as your version, but it is a conceptual | simplification, and it does allow generic classes like | | class MonadST s m | m -> s where | liftST :: Control.Monad.ST.ST s a -> m a | | with instances for IO, both ST's and various constructed monads, so we | could have the likes of | | readSTRef' :: MonadST s m => STRef s a -> m a | readSTRef' r = liftST (Data.STRef.readSTRef r) | | My problem with exposing the GHC implementation of IO is that I don't | think it's the Truth, and Haskell has a record of punishing untruths | sooner or later. | | > I think this would be fine for GHC. It might not be fine for Hugs | > because they implement IO and ST differently I think. No idea about | > NHC. | | NHC doesn't have ST (rank-2 types). In Hugs, they are now | | newtype IO a = IO ((a -> IOResult) -> IOResult) | newtype ST s a = ST (forall r. (a -> r) -> r) | | primitive newIORef "newRef" :: a -> IO (IORef a) | primitive newSTRef "newRef" :: a -> ST s (STRef s a) | | But I'm not proposing that this be exposed. | | > Or, alternatively, is the question something to do with the internals of | > the library, of interest to implementers but not to users of the | > library? Or is it just to do with the type of stToIO, which should be | > | > stToIO :: ST IORegion a -> IO a | | It's more a matter of making IORegion work a bit harder since we have to | put it in the interface anyway.

2 1