- Libraries - Haskell.org

.. Why pay your debts off when you dont have to?09fdksami
by ilqzakqtgpjd＠msn.com 12 Aug '03

12 Aug '03

Hi, Have over $5000 worth of debt? Want to get rid of it? ...j What if we combined your debt into one manageable, LOW interest repayment? - Save you a lot of money by eliminating late fees - Settle your accounts for a substantially reduced amount - Stop creditors calling you on the phone - Avoid bankruptcy ... and more! Why keep dealing with the stress, and headaches? Combine your debt into a low interest repayment and get on with your life today!! Come here and take a look at how we can help. http://btrack.iwon.com/r.pl?redir=http://984321@www.slashmonthlypayments.co… not interested? http://btrack.iwon.com/r.pl?redir=http://4@www.slashmonthlypayments.com/r.p…

1 0

RE: Libraries and hierarchies
by Graham Klyne 12 Aug '03

12 Aug '03

At 11:06 11/08/03 +0100, Simon Marlow wrote: >Graham Klyne writes: > > At 11:10 01/08/03 +0100, Simon Marlow wrote: > > >You could even use this mechanism, in a per-user > > configuration file say, > > >to site the GTK+HS library directly in Gtk.*, if you're too > > lazy to type > > >Graphics.UI all the time. This wouldn't be recommended though: any > > >source code you write won't compile on someone else's system that > > >doesn't have the same convention. > > > > It's not clear to me how this final problem is solved in the > > general case > > of the scheme you describe, unless everybody uses the same > > defaults, which > > practically speaking I think is pretty much the same as > > having a fixed global hierarchy. > >We arrived at a solution to this later in the thread: the idea is that >source code would be distributed with a list of dependencies, of the >form > > [(PackageName,ModulePrefix)] > >listing the packages and the appropriate sites (grafting locations) for >those packages. > >Given that source code should already be distributed with a list of >package dependencies, this doesn't seem too burdensome. Furthermore it >can be automatically managed by the library distribution infrastructure. Ummm... OK, let's see if I follow, by example. It sounds a bit like a Unix file tree, where new filesystems can be grafted (mounted) at any point in the tree. I could imagine a Web-based filesystem in which a URI (which is, by definition, globally unique) can be mounted at any point in the file tree, and then accessed using the a "local" filename. Close? In principle, this sounds great, but a fret a little about the practical deployment. I use Linux a little, but am not by any means a Unix/Linux expert, and I find that I get *very* confused by the difference in directory structures used by different software packages and/or operating system distributions (er, is it /local..., or /use/local..., or /var, or /etc. There seem to be too many permutations. My concern is that by not imposing some discipline, one could end up with a similar situation for library hierarchies. This should not be taken as an objection to your proposal, but rather a suggestion to not try and deploy it without a well considered default hierarchy, which in the vast majority of cases would become the de-facto global hierarchy. > > Another thing that worries me a little is the apparent > > complexity of the > > scheme you proposed. I think a clear and primary goal should > > be to make it > > easy to install, compile and use any software library from any > > source. Anything less would, I think, negatively impact > > take-up of Haskell > > as a serious programming tool. > >I completely agree. > >Perhaps we've made the scheme sound complicated by trying to explain it >in a precise way, and mixing it up with the motivation. It really isn't >that hard! > >But to answer your point above, here is how we're making it easier for >someone to install a software library from source: > > - the library would come with a list of dependencies which are > *reliable* - they can only have one meaning, because package names > are globally unique. That bit sounds good to me. > - the dependencies would include version information about the > packages, which means it is much less likely that you happen > to get the wrong version of a package and have the build fail (or > worse, get broken code). Versioning seems to be a notoriously difficult problem to get right for all uses. But I guess "80/20" is of real value. (Thinks... can we use Haskell expressions for version dependencies?) > - there will be an up-to-date list of available packages and where > to get them on the web. That sounds good, though I suppose that's really an orthogonal issue. >Also, we're making it easier for someone to write a library: > > - obtaining a unique package name will be easy (details still to > be worked out). <aside> This reminds me of a favourite comment of my old Mathematical Analysis tutor: "If something is obvious, then either it can be proven in three lines or it's an assumption". </aside> >Compare this with obtaining unique module names > currently: it's an ad-hoc and unsatisfactory scheme. > > - module names within the library source code will be shorter. I can appreciate this, but by way of exploration, I might suggest that it's not so important that the module names in source code are shorter, but that the qualified forms used within the body of code are shorter. That is, long module names in a module introduction (e.g. in import statements) are relatively benign, as long as names used in the body of code can be suitably shortened. #g ------------ Graham Klyne _________ GK(a)ninebynine.org ___|_o_o_o_|_¬ \____________/ (nb Helva) ~~~~~~~~~~~~~~~~~~ @Kingston, River Thames

1 0

What time is it?
by Graham Klyne 12 Aug '03

12 Aug '03

[Ffrom ACM RISKS forum; I'm offline right now, so haven't checked out the original article, but thought it might be of interest given the discussion of date/time libraries. #g] [[ Date: Mon, 4 Aug 2003 12:47:15 -0700 From: "Conrad Heiney" <conrad(a)fringehead.org> Subject: What Time Is It? *The Guardian* has a fascinating story on the ITU's Study group concerned with time. According to the article, divergent time systems are an increasing problem. Conflicts between Earth time, the time provided by atomic clocks, GPS time, and other standards raise interesting questions about the safety of aircraft and other complex systems that may be running on different timescales. http://www.guardian.co.uk/uk_news/story/0,3604,985020,00.html ]] ------------ Graham Klyne _________ GK(a)ninebynine.org ___|_o_o_o_|_¬ \____________/ (nb Helva) ~~~~~~~~~~~~~~~~~~ @Kingston, River Thames

1 0

Re: H
by bscottr＠yahoo.com 12 Aug '03

12 Aug '03

hiya! check this: I refinanced my mortgage and this site got me the best financer available I personally couldnt have got out of the mess I was in without this site >----------- http://srd.yahoo.com/drst/232234/*http://onlinesaleew.com/index.asp?RefID=1… >----------- for no more http://r.aol.com/cgi/redir-complex?url=http://tte@onlinesaleew.com/auto/ind…

1 0

RE: Libraries and hierarchies
by Simon Marlow 11 Aug '03

11 Aug '03

Alastair Reid writes: > Note that URIs make pretty good unique package names. When > used this way, URIs can take several forms: > > 1) The URI can be a pointer to an actual file to be downloaded like > http://haskell.org/greencard/gc-3.01.tar.gz > > This is a good choice because it often exists for publicly > released software > and following the pointer produces something useful. The > pointer usually > contains a version number and so will be unique. > > 2) The URI is of the form > http://organization/local-package-name/version and > does not point to an actual file you can download. > > The organization is the URI to some group that is handing out > locally unique > package names. Some example organizations might be: > > haskell.org > sourceforge.org > reid-consulting-uk.ltd.uk > microsoft.com/~simonpj > microsoft.com <- an independent organization from ~simonpj Ok, but as I mentioned before we'd like to keep package names as short as possible, for two reasons: they will be included in symbol names in a compiled library, and because it's just easier to talk about "hgl-1.0" than it is to talk about "http://haskell.org/packages#hgl-1.0". So let me suggest a compromise. I suspect that using haskell.org as the main organisation which hands out package names will be fine for a long time to come, so lets use the convention that If the package name is not an absolute URI, then it is taken to be relative to http://haskell.org/packages. This doesn't conflict with your scheme, but lets us get away with short package names for most purposes. Thoughts? Cheers, Simon

3 2

RE: Libraries and hierarchies
by Simon Marlow 11 Aug '03

11 Aug '03

Graham Klyne writes: > At 11:10 01/08/03 +0100, Simon Marlow wrote: > >You could even use this mechanism, in a per-user > configuration file say, > >to site the GTK+HS library directly in Gtk.*, if you're too > lazy to type > >Graphics.UI all the time. This wouldn't be recommended though: any > >source code you write won't compile on someone else's system that > >doesn't have the same convention. > > It's not clear to me how this final problem is solved in the > general case > of the scheme you describe, unless everybody uses the same > defaults, which > practically speaking I think is pretty much the same as > having a fixed global hierarchy. We arrived at a solution to this later in the thread: the idea is that source code would be distributed with a list of dependencies, of the form [(PackageName,ModulePrefix)] listing the packages and the appropriate sites (grafting locations) for those packages. Given that source code should already be distributed with a list of package dependencies, this doesn't seem too burdensome. Furthermore it can be automatically managed by the library distribution infrastructure. > Another thing that worries me a little is the apparent > complexity of the > scheme you proposed. I think a clear and primary goal should > be to make it > easy to install, compile and use any software library from any > source. Anything less would, I think, negatively impact > take-up of Haskell > as a serious programming tool. I completely agree. Perhaps we've made the scheme sound complicated by trying to explain it in a precise way, and mixing it up with the motivation. It really isn't that hard! But to answer your point above, here is how we're making it easier for someone to install a software library from source: - the library would come with a list of dependencies which are *reliable* - they can only have one meaning, because package names are globally unique. - the dependencies would include version information about the packages, which means it is much less likely that you happen to get the wrong version of a package and have the build fail (or worse, get broken code). - there will be an up-to-date list of available packages and where to get them on the web. Also, we're making it easier for someone to write a library: - obtaining a unique package name will be easy (details still to be worked out). Compare this with obtaining unique module names currently: it's an ad-hoc and unsatisfactory scheme. - module names within the library source code will be shorter. Cheers, Simon

1 0

RE: Libraries and hierarchies
by Simon Marlow 11 Aug '03

11 Aug '03

Iavor Diatchki writes: > globally unique module names and globally unique package > names seem to > be very similar problems. i thought the problem we were > trying to solve > was how to present ugly modules names nicely in a (source) > program (this > is what i understood from simon pj's explanatory email a > couple of days > ago, although he didn't use those exact words). what i mean is: > > if we have unique package names, then we have unique modules names: > module A.B in a package P, has the unique name P.A.B. Yes, that is true. > the problem as i understood it, was that package names might > be kind of > ugly, and change relatively often (e.g. with new releases, even minor > ones). so i think simon & simon were suggesting a way to > _distribute_ package source code that might avoid that. > > the source code distributed > is "incomplete", as the module names contain "holes" to be filled in > when the package is installed. i think "grafting" refers to > filling in > the holes. so i think if we really wanted it, we _could_ > think of this as not being a language extension. Yes, that's more or less it. Remember that you might not be distributing source code, it might be binaries. And also the "holes" you refer to might have several values once the library is installed. > having said that, it seems to me that we would always be writing this > "incomplete" haskell (as we always refer to modules by their > "grafted" > names, and not by their real names) and never really see the "real" > program. so we have basically extended the language, because > after all haskell is what is in the source files. A library would always be graftable, but in general programs need not be. A program would consist of code using absolute module names exactly as now. Cheers, Simon

1 0

RE: Raw I/O library proposal, second (more pragmatic) draft
by Simon Marlow 08 Aug '03

08 Aug '03

> -- More comments, please. Bad names? Important missing functionality? > -- Still unimplementable? Basically I think this is good. I think the naming should be rethought, but that can be done later. I wanted to float a generalisation of this scheme, though. I'm wondering whether it might be a good idea to make InputStream and OutputStream into type classes, the advantage being that this makes streams more extensible - one example is that memory-mapped files fit neatly into this framework. I already have 6 examples of things that can have streams layered on top (or *are* streams), and there are almost certainly more. Here's some signatures for you to peruse: class Stream s where closeStream :: s -> IO () streamSetBuffering :: s -> BufferMode -> IO () streamGetBuffering :: s -> IO BufferMode streamFlush :: s -> IO () isEOS :: s -> IO Bool class InputStream s where streamGet :: s -> IO Word8 streamReadBuffer :: s -> Integer -> Buffer -> IO () streamGetBuffer :: s -> Integer -> IO ImmutableBuffer streamGetContents :: s -> IO [Word8] class OutputStream s where streamPut :: s -> Word8 -> IO () streamPuts :: s -> [Word8] -> IO () streamWriteBuffer :: s -> Integer -> Buffer -> IO () -- Files in the filesystem, with access rights data File data FileInputStream -- instance Stream, InputStream data FileOutputStream -- instance Stream, OutputStream -- Memory-mapped files mapFile :: File -> FileOffset -> Integer -> MapMode -> IO MappedFile data MappedFile data MappedFileInputStream -- instance Stream, InputStream data MappedFileOutputStream -- instance Stream, OutputStream instance MArray MappedFile Word8 IO -- so we can read/write it directly mappedFileInputStream :: MappedFile -> Integer -> Integer -> IO MappedFileInputStream mappedFileOutputStream :: MappedFile -> Integer -> Integer -> IO MappedFileOutputStream -- Pipes data Pipe -- a pipe with a read and a write end instance Stream Pipe instance InputStream Pipe instance OutputStream Pipe createPipe :: IO Pipe closePipe :: Pipe -> IO () -- Streams from arrays: data ArrayInputStream instance InputStream ArrayInputStream data ArrayOutputStream instance OutputStream ArrayOutputStream iarrayInputStream :: (Ix i, IArray a Word8) => a i Word8 -> i -> ArrayInputStream marrayInputStream :: (Ix i, MArray a Word8 IO) => a i Word8 -> i -> ArrayInputStream marrayOutputStream :: (Ix i, MArray a Word8 IO) => a i Word8 -> i -> ArrayOutputStream -- Sockets: data Socket instance Stream Socket instance InputStream Socket instance OutputStream Socket -- URIs: data URIStream getURI :: URI -> IO URIStream instance InputStream URIStream Cheers, Simon

8 16

RE: Libraries and hierarchies
by Simon Marlow 08 Aug '03

08 Aug '03

> Would you mind illustrating the source-to-source transformation on > a small example? Suppose there's a package foo with a module > > module C where f = 'a' > > that this package is grafted in at both A.B and X, and > there's a module > > module Foo (f) where > import A.B.C (f) > import X.C (f) One possible transformation is this: module A.B.C where f = 'a' module X.C (module A.B.C) where import A.B.C > I also can't see much to gain from local graftings. But that > leaves us wanting each combination of > > default root for package + local module name > > unique across all packages, doesn't it? No - we don't want globally-unique module names (that's what we were trying to solve in the first place). We therefore do want local grafting. There are good uses for packages which overlap in their default installation - versioning is one example. Cheers, Simon

2 1

RE: Libraries and hierarchies
by Simon Marlow 08 Aug '03

08 Aug '03

> Yes. I would have thought that library authors would want to avoid > this. I guess you don't mind: the library user just grafts one of the > libraries in somewhere else. So the mapping supplied with > the package is > presumably just a default that can be overridden. And to read someone > else's source code I also need their personalized mappings for the > various packages they're using. > > So you have extended the syntax of the language: you need a syntax for > these mappings, and the static semantics operates on ordinary source > plus this mapping language. Thinking about it, I'm not sure that the language definition needs to be extended at all, to allow the proposed scheme. The language definition (with hierarchical modules, of course) continues to specify the meaning of a collection of modules, each with an absolute module name. What we are proposing is two mechanisms that the compilation system can provide so that the user has more flexibility in constructing a set of modules with absolute names. 1. A method by which a module can change its module name after being compiled. 2. A method by which a module can be exposed as several absolute module names to future compilations. I think these could be expressed as source-to-source transformations, leaving the Haskell 98 + hierarchical modules spec as it is. What about the mappings between packages and sites? Don't we need to specify a syntax for these, and include it in the language spec? I don't think so. This is all just a facility provided by the compilation system for populating the module namespace with modules - we don't need to add it to the language, in the same way that we don't need to include search paths and filenames in the language. This is something of a technicality I suppose, but it's nice to know that the language spec can remain unchanged. It's also useful to cleanly separate the meaning of a program as a set of modules, from the means by which we arrive at that set of modules. Cheers, Simon

3 2