Re: [Haskell-cafe] RE: Definition of the Haskell standard library
Hugh Perkins wrote: On 9/3/07, Adrian Hey [EMAIL PROTECTED] wrote: The popularity of MS Winders or Office Suite are the obvious examples. We all know why these are used on 95% or whatever of the worlds PCs, and it has nothing whatever to do with quality. Oh come on. You've been reading waaayyy too much Slashdot... Nope. Would it be too hard to believe that I really do have a mind of my own, just like you? FYI, I am old enough to actually remember life before MS and I can also remember what's happened to the industry at large and to various the organisations I've worked in and had dealings with over the last 25 years or so. Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: Definition of the Haskell standard library
On 9/3/07, Adrian Hey [EMAIL PROTECTED] wrote: FYI, I am old enough to actually remember life before MS and I can also remember what's happened to the industry at large and to various the organisations I've worked in and had dealings with over the last 25 years or so. Fair enough. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: Definition of the Haskell standard library
On Sunday 02 September 2007 03:29, Hugh Perkins wrote: A really simple way to track the quality of a package is to display the number of downloads. A posteriorae, this works great in other download sites. We can easily hypothesize about why a download count gives a decent indication of some measure of quality: [...] ... and even more easily hypothesize why this is not always a good indication: High-qualitiy standard libraries which are packaged with GHC/Hugs/... will probably almost never be downloaded separately. Cheers, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: Definition of the Haskell standard library
On 9/2/07, Sven Panne [EMAIL PROTECTED] wrote: High-qualitiy standard libraries which are packaged with GHC/Hugs/... will probably almost never be downloaded separately. Good point. Note however that if someone is hunting for a library, it's generally because it's not already bundled with their default ghc install ;-) Sucks for hugs users I know ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: Definition of the Haskell standard library
Sven Panne wrote: ... and even more easily hypothesize why this is not always a good indication: High-qualitiy standard libraries which are packaged with GHC/Hugs/... will probably almost never be downloaded separately. Solution: change GHC/Hugs so it submits usage counters of which libraries the user imports to a webservice, stored in a database ;-) Of course this is subject to the user accepting such a feedback, to protect it's privacy. Google does this all the time! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: Definition of the Haskell standard library
Sven Panne wrote: ... and even more easily hypothesize why this is not always a good indication: High-qualitiy standard libraries which are packaged with GHC/Hugs/... will probably almost never be downloaded separately. Solution: change GHC/Hugs so it submits (via a webservice, stored in a database) usage counters of which libraries the user imports ;-) Of course this is subject to the user accepting such a feedback, to protect its privacy. Google does this all the time... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: Definition of the Haskell standard library
Hugh Perkins wrote: A really simple way to track the quality of a package is to display the number of downloads. A posteriorae, this works great in other download sites. We can easily hypothesize about why a download count gives a decent indication of some measure of quality: - more people downloading it means more people specifically wanted that package - more people downloading it means more people trying it, giving feedback, maybe giving patches - and, of course, it's an objective measure, easy to do I don't agree. The idea that any arbitrary objective measure provides any indication quality seems quite wrong to me, especially this one. The problem is the effect of positive feedback. The popularity of MS Winders or Office Suite are the obvious examples. We all know why these are used on 95% or whatever of the worlds PCs, and it has nothing whatever to do with quality. Or a little closer to home, the popularity of Haskell vs. Clean. Other meaningless measures that have been suggested are the rate of patch submissions of the number of developers involved. I seem to remember someone recently suggesting that libraries that score highly in on this regard should be elevated to blessed status. I cynic like me could just as well regard this as an indication of the complete opposite, that the library was being developed by an uncoordinated troop of barely competent code monkeys desperately trying to produce something that works reliably by a process of trial and error :-) Personally the first things I tend to look at are things like the quality of documentation and the presence of of some kind of test suite. Both these are IMO opinion pretty reliable indications that the author(s) have actually devoted some time and effort into deciding what it is that the library aims to achieve and have designed a coherent API (and have made reasonable effort to ensure that it actually works). I tend lose interest pretty fast if even basic Haddock API documentation is either non-existant, or consists of nothing but type signatures, or that plus broken link to some ancient postscript paper. Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: Definition of the Haskell standard library
2007/9/2, Adrian Hey [EMAIL PROTECTED]: Other meaningless measures that have been suggested are the rate of patch submissions of the number of developers involved. I seem to remember someone recently suggesting that libraries that score highly in on this regard should be elevated to blessed status. I don't see them as completely meaningless, such a library is more likely to be corrected if you report a bug, and if a library lacks certain features but seems interesting, I'm less inclined to give it a chance if nobody worked on it for years than if there's an active community, frequent update and a roadmap. Still it's not sufficient, I agree with you. Personally the first things I tend to look at are things like the quality of documentation and the presence of of some kind of test suite. Both these are IMO opinion pretty reliable indications that the author(s) have actually devoted some time and effort into deciding what it is that the library aims to achieve and have designed a coherent API (and have made reasonable effort to ensure that it actually works). I tend lose interest pretty fast if even basic Haddock API documentation is either non-existant, or consists of nothing but type signatures, or that plus broken link to some ancient postscript paper. Yes, those are some of the more interesting metrics, the CPAN try to take them into account with the recent Kwalitee metric. Thing is we probably won't find _the best_ metric (if such a thing existed, I think it will already have been found) but we can try to give some useful indications. -- Jedaï ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: Definition of the Haskell standard library
On 9/3/07, Adrian Hey [EMAIL PROTECTED] wrote: The popularity of MS Winders or Office Suite are the obvious examples. We all know why these are used on 95% or whatever of the worlds PCs, and it has nothing whatever to do with quality. Oh come on. You've been reading waaayyy too much Slashdot... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: Definition of the Haskell standard library
On Tuesday 31 July 2007 19:39, Duncan Coutts wrote: [...] The docs for those packages would be available for packages installed via cabal (assuming the user did the optional haddock step) and would link to each other. Well, on a normal Linux distro a user should *never* have to call cabal (or any of its cousins) directly, the distro's package manager should be the used instead. On an e.g. RPM system, the .spec file would use Cabal to e.g. (un-)register a package, because RPM has to know what is installed, which other packages are prerequisites, how to cleanly uninstall, etc. IMHO Cabal should not try to mirror a full-fledged package system, simply because on every (non-Windows ;-) platform there are tons of native tools for this purpose, and Cabal is not in the driver's seat when it comes to SW installation. What is missing from the local docs is a single integrated index page that lists all the modules and then links off to the various packages's docs like we have on the ghc website. The problem with generating one of those is what manages it? What package would it belong to etc. Of course we are not the first project to face this kind of problem: Texinfo offers a central contents page as well. To maintain this page, it comes with a tool install-info, which updates the index page after (de-)installation. On RPM systems, the .spec file calls install-info after (de-)installation of a package with info pages. http://www.gnu.org/software/texinfo/manual/texinfo/html_node/Installing-an-Info-File.html On some systems (windows, gnome) there are dedicated help viewers that can help with this contents/index issue. haddock supports both (mshelp, devhelp). I'm not sure everyone would find that a sufficient solution however. A install-haddock tool would be the solution IMHO. Cheers, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: Definition of the Haskell standard library
As a enthusiast Perl user over the years, I note that the CPAN and the associated toolkit (the CPAN module, its shell, ExtUtils::MakeMaker and Module::Build) is pretty good at this. It has it's share of cruft (in fact a whole lot of it) but it's certainly better than most solutions in this field in my eye. Perl already has it's own centralised documentation on the CPAN and local copies are installed and accessible through the command line tool perldoc and miscellanous other modules that allows a more pleasant esthetic experience (Pod::POM::Web is pretty good at this, it even comes with it's own little http server and allow you to search your local doc in many way). It might be worth keeping an eye on the development of the CP6AN if it ever comes to life (I'm a firm Perl6 believer but some don't share this belief, with some justifications I fear)... Cabal is an interesting experiment but it just don't compare for now. -- Jedaï ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: Definition of the Haskell standard library
On Sat, 2007-09-01 at 18:47 +0200, Sven Panne wrote: On Tuesday 31 July 2007 19:39, Duncan Coutts wrote: [...] The docs for those packages would be available for packages installed via cabal (assuming the user did the optional haddock step) and would link to each other. Well, on a normal Linux distro a user should *never* have to call cabal (or any of its cousins) directly, the distro's package manager should be the used instead. On an e.g. RPM system, the .spec file would use Cabal to e.g. (un-)register a package, because RPM has to know what is installed, which other packages are prerequisites, how to cleanly uninstall, etc. IMHO Cabal should not try to mirror a full-fledged package system, simply because on every (non-Windows ;-) platform there are tons of native tools for this purpose, and Cabal is not in the driver's seat when it comes to SW installation. I think it's inevitable that there will always be a mixture of packages that are managed by the system package manager and ones that are too insignificant to be packaged by the distro. So cabal-install should cooperate with the system package manager somehow. Another strategy would be to have tools that the users can use to generate system packages from cabal packages and then install those via the system package manager. We already have such tools for rpm and gentoo ebuilds. Again, these would be for the case of less significant package that the distro does not package itself. For example, gentoo has a tool that can be used to install perl CPAN packages via the system package manager, since there are many 1000's of CPAN packages and only a few hundred of those are included in the main portage collection. There are other cases not covered by system package managers, like unprivileged user installations under $HOME. The problem with generating one of those is what manages it? What package would it belong to etc. Of course we are not the first project to face this kind of problem: Texinfo offers a central contents page as well. To maintain this page, it comes with [..] A install-haddock tool would be the solution IMHO. That re-generates the index page, right. Perhaps haddock itself should be extended with this ability. All it should need to do is read all the .haddock files that ghc-pkg knows about and generate the index page from that. I assume the .haddock files contain enough information to do this, or it could be modified to include enough. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: Definition of the Haskell standard library
A really simple way to track the quality of a package is to display the number of downloads. A posteriorae, this works great in other download sites. We can easily hypothesize about why a download count gives a decent indication of some measure of quality: - more people downloading it means more people specifically wanted that package - more people downloading it means more people trying it, giving feedback, maybe giving patches - and, of course, it's an objective measure, easy to do ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: Definition of the Haskell standard library
Simon Peyton-Jones wrote: When you install packages A,B,C, the documentation for A,B,C (and nothing else) ought to be locally available as an integrated whole, much as at the GHC web site. I don't know whether Cabal does, or could do, that, but it's surely what one would expect. and would take some educating of users, like me who tend to use online resources even when there are equivalent local files available. Maybe mentioning it in the User's Guide or somewhere on the website would be enough. Actually sometimes I user-install library packages, not for the whole system; then should there be an integrated whole anywhere? Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Definition of the Haskell standard library
Chris Smith wrote: Can someone clarify what's going on with the standard library in Haskell? As of right now, I can download, say, GHC from haskell.org/ghc and get a set of libraries with it. I can visit http://haskell.org/ghc/docs/latest/html/libraries/, linked from the haskell.org home page, and see descriptions of all of those libraries. I can build with --make (or if I'm feeling masochistic, add several lines of -package options) and it works. That's all great. I've seen some stuff lately on -libraries and this list indicating that there's an effort to change this. People asking whether something should be included in the standard library are being told that there is no standard library really. I'm hearing that the only distinction that matters is used by GHC or not used by GHC, and that being on hackage is as official as it gets. Am I misunderstanding? Is there something awesome about Hackage that I'm not seeing? My take on it is this: Hackage is a pre-requisite for a comprehensive well-maintained standard library. We don't have a comprehensive standard library yet, but from Hackage will emerge a large number of components that will someday be reviewed and filtered by a group of people who define the standard library. This might be part of the Haskell prime effort, or a subsequent library standardisation process. I agree that a standard library is important, I also believe it's vital that we have an effective distributed collaborative mechanism by which good libraries can emerge. In the early days of the hierarchical libraries I think we tried to define a defacto standard set of libraries which we shipped with the various compilers; I now believe the distributed model will achieve better results in the long run, and the rate at which Hackage is growing seems to back this up. This is why we developed the package system and Cabal, and why we no longer have a single global module namespace - every package author has the right to independently choose what their modules are called. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: Definition of the Haskell standard library
On Tue, 2007-07-31 at 10:15 +0100, Simon Peyton-Jones wrote: - Package X is blessed; lots of people have argued over its design, it's stable, widely used, and actively maintained. Changes to this package goes through a quality-control process. Then, in effect, the standard library is all the X packages. Duncan Coutts [EMAIL PROTECTED] wrote: I'm not sure that belongs in the cabal file, afterall, being blessed is a central community consensus thing, not a distributed decision taken by each person writing the cabal file for their package. I can't make a blessed package by just saying that it is so. Yes, pretty much. The ideas mentioned in this thread for Hackage sound great. I definitely was missing a lot there, as I thought of Hackage as just somewhere people could upload their libraries. If there could be built-in quality control in promoting certain packages, that would be great. Even greater would be if: 1. Hackage tracked which packages had this blessed status. 2. There were a simple automated way, as part of the GHC install or otherwise immediately visible without knowing about it ahead of time, to download the whole set and install them. 3. There were either (a) a single URL that can be used to see documentation for all of them without worrying about which package something is in first; or (b) something like Cabal's haddock and install steps would combine documentation for all installed packages into a single URL; or even better, (c) both. I see it as a really big deal that documentation becomes fragmented when one is using many packages, so that it's harder to find what you want. In fact, I'd classify that as the single biggest reason that I don't use many packages now; they aren't documented at http://haskell.org/ghc/docs/latest/html/libraries/, and it's a pain to keep open several windows with documentation for different libraries. (I already have done it a lot for gtk2hs and happs, but at least it's a Big Deal to be using those, so one can justify the extra window!) So it's clear at the moment that the base package is blessed, changes to it go through the library submissions process. It's not so clear for the other packages that ghc has distributed and have often been taken to be the standard library. Many of them look more like Y's above (like parsec, regex-*). I've always thought of at least these packages in the existing standard library as being pretty stable: base, arrows, stm, mtl, Cabal, haskell-src, template-haskell, network, process, directory, filepath, unix, random, parsec, and pretty. Perhaps my perception has been skewed... but given how often these things are recommended, I'd hope they are stable. Even then though, I think Chris was looking for something slightly wider. I'm not entirely sure I can articulate precisely what I'm looking for. It sounds like things are going in a reasonable direction. I'll try to get my head around it, and see if I can pitch in somehow. I was simply worried that from an outsider's perspective, several recent comments in various mailing list threads, IRC dicussions, etc. seemed to predict the demise of any standard library except for base -- which would be quite disturbing given that base is becoming smaller, not larger, over time. What is not clear to me yet is if we should just rely on mechanisms in hackage to distinguish the gems from the failed experiments or something more centralised. Good question. I would guess the best way to answer it is to simultaneously establish something centralized in the short term, and then try to develop the technological structures to make it obsolete. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: Definition of the Haskell standard library
On Tue, Jul 31, 2007 at 09:16:33AM -0600, Chris Smith wrote: If there could be built-in quality control in promoting certain packages, that would be great. it needs to be more fine grained. a new version of a package may indeed rollback some positive attributes (stability for example) that a previous version demonstrated...perhaps intentionally (when an author is choosing to break an api, etc), perhaps not (plain old bugs) we already have quality claims of two kinds for hackage packages: implicit (version number, 0.* indicating lack of maturity) and explicit (stability: experimental, stable, etc). allowing two scores to be maintained for stability - author score AND audience score, seems like a good way of moderating claims. simply allow people with haskell.org accounts to select a pulldown in the package listing with options for the stability score, with obvious safety features (one vote per account per package version, etc) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] RE: Definition of the Haskell standard library
| I see it as a really big deal that documentation becomes fragmented when | one is using many packages, so that it's harder to find what you want. | In fact, I'd classify that as the single biggest reason that I don't use | many packages now When you install packages A,B,C, the documentation for A,B,C (and nothing else) ought to be locally available as an integrated whole, much as at the GHC web site. I don't know whether Cabal does, or could do, that, but it's surely what one would expect. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: Definition of the Haskell standard library
On Tue, Jul 31, 2007 at 05:26:31PM +0100, Simon Peyton-Jones wrote: | I see it as a really big deal that documentation becomes fragmented when | one is using many packages, so that it's harder to find what you want. | In fact, I'd classify that as the single biggest reason that I don't use | many packages now When you install packages A,B,C, the documentation for A,B,C (and nothing else) ought to be locally available as an integrated whole, much as at the GHC web site. I don't know whether Cabal does, or could do, that, but it's surely what one would expect. I don't think that would be terribly hard. We would need to modify Haddock with the ability to generate links following a schema like /usr/share/doc/libghc6-$lowercasepackagename/html/$modulepath.html; this would be fairly easy with Haddock-GHC's ability to access package names and ghc-pkg haddock data, assuming Cabal and Haddock-GHC are fixed to work on the same system... Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] RE: Definition of the Haskell standard library
On Tue, 2007-07-31 at 17:26 +0100, Simon Peyton-Jones wrote: | I see it as a really big deal that documentation becomes fragmented when | one is using many packages, so that it's harder to find what you want. | In fact, I'd classify that as the single biggest reason that I don't use | many packages now When you install packages A,B,C, the documentation for A,B,C (and nothing else) ought to be locally available as an integrated whole, much as at the GHC web site. I don't know whether Cabal does, or could do, that, but it's surely what one would expect. The docs for those packages would be available for packages installed via cabal (assuming the user did the optional haddock step) and would link to each other. What is missing from the local docs is a single integrated index page that lists all the modules and then links off to the various packages's docs like we have on the ghc website. The problem with generating one of those is what manages it? What package would it belong to etc. On some systems (windows, gnome) there are dedicated help viewers that can help with this contents/index issue. haddock supports both (mshelp, devhelp). I'm not sure everyone would find that a sufficient solution however. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] RE: Definition of the Haskell standard library
Duncan Coutts [EMAIL PROTECTED] wrote:
What is missing from the local docs is a single integrated index page
that lists all the modules and then links off to the various packages's
docs like we have on the ghc website.
The problem with generating one of those is what manages it? What
package would it belong to etc.
Locally, I've kludged things together to add to the documentation
package that GHC builds. That may be the wrong place, but it kinda
works anyway. This script gets you much of the way there (with some
unfortunate line wrapping at the end that you'd have to fix). Of
course, the script does more than just build haddock; and there are
several other quirks here to that were needed to get random stuff to
work for some packages, and unfortunately there are a number of packages
for which it seems that 'runhaskell Setup haddock' just doesn't work at
all due to use of features in the source that haddock can't parse.
What it doesn't do is fix up the links to contents and index from the
other packages so that they point back to the right place.
-- begin attached script --
#!/bin/sh
ghcver=`ls -d /usr/local/lib/ghc-* | sort`
ghcver=`expr match $ghcver '.*\(ghc-6.7.[0-9]*\)'`
sudo rm /usr/local/lib/${ghcver}/share
sudo ln -s /usr/local/share /usr/local/lib/${ghcver}/share
sudo cp ../ghc/libraries/libraries-*.txt /usr/local/share/ghc/doc/html
for ln in `cat packages.list`
do
d=${ln:0:1}
p=${ln:1}
echo ===
echo == BUILDING: $p
echo ===
echo $d $p
cd $p || exit 1
if [ -d _darcs ]
then
darcs pull || exit 1
fi
if [ -f configure.in -o -f configure.ac ]
then
autoreconf || exit 1
fi
if [ -f Setup.hs -o -f Setup.lhs ]
then
runhaskell Setup clean || exit 1
runhaskell Setup configure || exit 1
runhaskell Setup build || exit 1
if [ $d = + ]
then
runhaskell Setup haddock --html-location=/usr/local/share/ghc \
|| exit 1
fi
sudo runhaskell Setup install|| exit 1
elif [ -f Makefile -o -f Makefile.in -o -f Makefile.am ]
then
if [ $d = + ]
then
echo Don't know how to run haddock
exit 1
fi
make distclean || true
./configure || exit 1
make || exit 1
sudo make install|| exit 1
else
echo Don't know how to make $p
exit 1
fi
cd ..
done
ls /usr/local/share/*/doc/html/*/haddock.css \
| grep -v '/usr/local/share/ghc' \
| sed 's/\(\/usr\/local\/share\/.*\/doc\/html\/\([^/]*\)\)
\/haddock.css/cp -r \1 \/usr\/local\/share\/ghc\/doc\/html\/\2 ; echo \2
\/usr\/local\/share\/ghc\/doc\/html\/\2\/prologue.txt/' \
| sudo /bin/sh
ls ../ghc/libraries/*/prologue.txt \
| sed 's/\(\.\.\/ghc\/libraries\/\([^\/]*\)\/prologue.txt\)/cp \1
\/usr\/local\/share\/ghc\/doc\/html\/\2/' \
| sudo /bin/sh
cd /usr/local/share/ghc/doc/html
sudo ./gen_contents_index
--
Chris Smith
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: Definition of the Haskell standard library
The problem with generating one of those is what manages it? What package would it belong to etc. the same package that provides us with our interactive hackage prompt rebuilding a central index will be a logical post-process for the installation function ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Definition of the Haskell standard library
Chris Smith cdsmith at twu.net writes: Can someone clarify what's going on with the standard library in Haskell? ... sites for the thousandth time before realizing that so-and-so's GUI library hasn't actually been touched since they finished their class Short answer: Our system is very democratic. Long answer: You remind me of the usual academic debate, what to do about students using the web to do research? There's a lot of uncertain information out there, the right answer is to teach discrimination skills. Put differently, take the most famous problem in computer science, P vs NP. If a genie in a bottle is going to lie to you a couple of times before telling you a truth you can easily check, you're still better off. In, say, Perl, it's all about the libraries. One connects lots of pieces one doesn't understand with short bits of line noise, and gets serious real-world work done. That's one pole in a range of attitudes. I may be near the other pole; in a hurry I'll use libraries included with GHC without looking at the source code. I view anything else in hackage as a truly awesome repository of sample code. It's on me to make sure that it works, or that I should be using it at all, rather than doing something else. My pet example is a PDF library. No language should have its own PDF library, when Postscript is so easy to write, and Ghostscript is a cross-platform conversion tool maintained by thousands of our best and brightest. So our Haskell desire to have lots of libraries is another version of How big should a language be? The Common Lisp specification has an appendix bigger than the Scheme specification in its entirety. I've gone through several cycles in the last decade of getting rid of half my possessions; I get more than twice the utility out of what's left, in part because I understand and I can find what's left. Programming languages are the same story; I prefer lean. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Definition of the Haskell standard library
On 2007-07-30, Dave Bayer [EMAIL PROTECTED] wrote: My pet example is a PDF library. No language should have its own PDF library, when Postscript is so easy to write, and Ghostscript is a cross-platform conversion tool maintained by thousands of our best and brightest. Except, of course, that there are PDF features that are not easily used by converting from PostScript. And then there's reading and parsing PDF... -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
