Re: Thinking about what's missing in our library coverage

newer
Improving event management in...

older
IFL 2009: Final Call for Papers...

Alexander Dunlap

4 Aug 2009 4 Aug '09

5:40 a.m.

On Mon, Aug 3, 2009 at 4:44 PM, Don Stewart wrote:

...

Following Simon M's advice, I look over the typical "batteries" categories, using Python as input:

http://docs.python.org/library/index.html

The following things were missing from the current Platform. There are many. How would you identify the top, say, 5 libs to add?

-- Don

* String support o pcre regexes [pcre-light] [regex-pcre] — what’s our best regex lib?

For something like this, it seems like all of the regex libs probably have pros and cons. It would be good if we could identify what these are and create a library that was the "best of all worlds" instead of just picking one and going with it.

...

o unicode text [text] [text-icu] — packed, unicode text

This is essential, although I don't know if it is stable enough for the platform (?).

...

* text o pandoc — markdown, reStructuredText, HTML, LaTeX, ConTeXt, Docbook, OpenDocument, ODT, RTF, MediaWiki, groff

No. Pandoc is too actively developed to go into the HP. It's also much more of an end-user application than a "standard library" - it's applications are not general enough to be included in the standard distribution.

...

* math and numerics o blas — BLAS o cmath — C math functions o dimensional — physical dimensions o fftw o mersenne-random — fast randoms

The interfaces here should be unified more to create a general Haskell numerical library, IMO.

...

* compression o bzip2 o zip o tar

Definitely.

...

* file formats o config parser

This would be quite useful.

...

* crypto o hmac, md5, sha, hashing

Yes.

...

* systems o getopt o logging o termio o editline o mmap

All of these, at some point.

...

* Internet o network-bytestring o ssl o json o feed (rss, atom) o mime o base64 et al o uuencode o cgi o fastcgi o urls o ftp, http, imap, smtp clients o uuid o url parsing o http server o xml-rpc

Interface unification would help. Especially network-bytestring seems to be too ad-hoc for me - it would probably be better to put ByteString support into the regular Network library....

...

* Internationalization o gettext o locale o i18n

Yes, although again, maturity?

...

* Development o hscolour

Yes. My main concern is with libraries like attoparsec and network-bytestring - these libraries seem to be somewhat ad-hoc conversion of traditional libraries to use ByteStrings. We should come up with a cleaner, more elegant way of dealing with the String/Text/Strict ByteString/Lazy ByteSTring gap, as most libraries that apply to one of those types also apply to the other two, as the first two and last two especially and more generally all four essentially represent the same thing. We shouldn't bless libraries that don't have a good way of applying equally to these three. A possible solution could be a standardized package-common, package-string, package-text, package-bytestring, package-lazybytestring naming convention, or a Category.Module, Category.Module.String, Category.Module.ByteString.Strict, Category.Module.ByteString.Lazy, Category.Module.Text convention. We could also work something up with type classes. I just don't like how a lot of libraries implement support for various string types just based on need rather than creating a clean, comprehensive interface. Alex

Show replies by date

Don Stewart

4 Aug 4 Aug

5:53 a.m.

New subject: Thinking about what's missing in our library coverage

alexander.dunlap:

...

...
o pandoc — markdown, reStructuredText, HTML, LaTeX, ConTeXt, Docbook, OpenDocument, ODT, RTF, MediaWiki, groff

No. Pandoc is too actively developed to go into the HP. It's also much more of an end-user application than a "standard library" - it's applications are not general enough to be included in the standard distribution.

One comment on your thoughtful post. What role does having unique capabilities for the Haskell Platform play? Our base library is already notable for having OpenGL support out of the box. Maybe markup/markdown formats (for example) would also help Haskell stand out from the crowd. A similar case would be gtk2hs out of the box (Python supplied Tcl guis). On the other hand, maybe the HP should be aiming to be comprehensive enough to /support/ pandoc without additional dependencies. We don't have to decide this now. There's more than enough "core" components missing to keep us busy for a while. -- Don

John MacFarlane

3:54 p.m.

New subject: Thinking about what's missing in our library coverage

+++ Don Stewart [Aug 03 09 22:53 ]:

...

alexander.dunlap:

...
...
o pandoc — markdown, reStructuredText, HTML, LaTeX, ConTeXt, Docbook, OpenDocument, ODT, RTF, MediaWiki, groff

No. Pandoc is too actively developed to go into the HP. It's also much more of an end-user application than a "standard library" - it's applications are not general enough to be included in the standard distribution.

One comment on your thoughtful post.

What role does having unique capabilities for the Haskell Platform play?

Our base library is already notable for having OpenGL support out of the box. Maybe markup/markdown formats (for example) would also help Haskell stand out from the crowd. A similar case would be gtk2hs out of the box (Python supplied Tcl guis).

On the other hand, maybe the HP should be aiming to be comprehensive enough to /support/ pandoc without additional dependencies.

I agree that pandoc shouldn't be in the HP. Also, although we ought to have a zip encoding package, I'm not sure it should be zip-archive (I'm the author). zip-archive is not complete; there are some kinds of zip files it can't parse. Quoting the documentation: "there is no support for encryption, zip files that span multiple disks, ZIP64, OS-specific file attributes, or compression methods other than Deflate." A better solution, perhaps, would be a binding to libzip. In this connection, I want to make a general point about the HP: In a way, it doesn't matter so much which additional pure Haskell libraries it includes, because once you have cabal install, you can get anything easily. For bindings to C libraries, it's another story. pcre-light is a good example. If I want to tell someone how to install pandoc with syntax highlighting, I can't just say, "Get the HP and then cabal install pandoc -fhighlighting". I have to say: "First, install the pcre library, if it's not already on your system..." -- and you lose a lot of users at this step. Havig high-quality, high-level bindings to standard libraries like pcre, libzip, etc., together with the C libraries themselves, in HP would be very useful. John

Magnus Therning

4:13 p.m.

New subject: Thinking about what's missing in our library coverage

On Tue, Aug 4, 2009 at 4:54 PM, John MacFarlane wrote: [..]

...

In this connection, I want to make a general point about the HP: In a way, it doesn't matter so much which additional pure Haskell libraries it includes, because once you have cabal install, you can get anything easily. For bindings to C libraries, it's another story.

AFAIU the plan is to separate GHC and its "platform packages", so in the future it might not be that easy to get to the point where you _can_ run 'cabal install'.

...

pcre-light is a good example. If I want to tell someone how to install pandoc with syntax highlighting, I can't just say, "Get the HP and then cabal install pandoc -fhighlighting". I have to say: "First, install the pcre library, if it's not already on your system..." -- and you lose a lot of users at this step.

This is a good point, but to some extent this brings us back to a discussion that's specific to systems with broken or non-existing package managers. Wouldn't it be better to deal with _that_ outside of HP? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

Max Rabkin

4:22 p.m.

New subject: Thinking about what's missing in our library coverage

On Tue, Aug 4, 2009 at 6:13 PM, Magnus Therning wrote:

...

AFAIU the plan is to separate GHC and its "platform packages", so in the future it might not be that easy to get to the point where you _can_ run 'cabal install'.

Absolutely not. The point of HP is to make the path from bare OS to complete Haskell installation including cabal-install consist of a single step: 1. Install Haskell Platform

...

This is a good point, but to some extent this brings us back to a discussion that's specific to systems with broken or non-existing package managers. Wouldn't it be better to deal with _that_ outside of HP?

AIUI, on systems with working package managers, HP will be a metapackage which depends on the appropriate "real" packages. --Max

Magnus Therning

9:56 p.m.

New subject: Thinking about what's missing in our library coverage

Max Rabkin wrote:

...

On Tue, Aug 4, 2009 at 6:13 PM, Magnus Therning wrote:

...
AFAIU the plan is to separate GHC and its "platform packages", so in the future it might not be that easy to get to the point where you _can_ run 'cabal install'.

Absolutely not. The point of HP is to make the path from bare OS to complete Haskell installation including cabal-install consist of a single step: 1. Install Haskell Platform

Yes, indeed, if there exists a pre-compiled, binary version of HP for your platform. Also, note that you _didn't_ say that the goal of HP is to limit the pain of installing bindings to C libraries.

...

...
This is a good point, but to some extent this brings us back to a discussion that's specific to systems with broken or non-existing package managers. Wouldn't it be better to deal with _that_ outside of HP?

AIUI, on systems with working package managers, HP will be a metapackage which depends on the appropriate "real" packages.

Yes, but again, the role of HP shouldn't be to limit the pain of installing bindings to C libraries. What I'm saying is that it's a worthwhile goal to limit that pain, but it should be handled outside of HP. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

Max Rabkin

10:05 p.m.

New subject: Thinking about what's missing in our library coverage

On Tue, Aug 4, 2009 at 11:56 PM, Magnus Therning wrote:

...

...
AIUI, on systems with working package managers, HP will be a metapackage which depends on the appropriate "real" packages.

Yes, but again, the role of HP shouldn't be to limit the pain of installing bindings to C libraries. What I'm saying is that it's a worthwhile goal to limit that pain, but it should be handled outside of HP.

How could one do that? On systems with package managers, the platform won't bundle C libraries, but depend on them (this is correct: if software does in fact depend on a C library, it should declare that dependency). On systems without package managers, we could provide some form of "sub-platform" containing C libraries or a system for installing them, but then installing a Haskell system is no longer a one-step process. It's been a while since I was a regular Windows user, but it seemed then that bundling dependencies was the most common (only?) solution.

...

/M

--Max

Magnus Therning

5 Aug 5 Aug

7:37 a.m.

New subject: Thinking about what's missing in our library coverage

On Tue, Aug 4, 2009 at 11:05 PM, Max Rabkin wrote:

...

On Tue, Aug 4, 2009 at 11:56 PM, Magnus Therning wrote:

...
...
AIUI, on systems with working package managers, HP will be a metapackage which depends on the appropriate "real" packages.

Yes, but again, the role of HP shouldn't be to limit the pain of installing bindings to C libraries. What I'm saying is that it's a worthwhile goal to limit that pain, but it should be handled outside of HP.

How could one do that? On systems with package managers, the platform won't bundle C libraries, but depend on them (this is correct: if software does in fact depend on a C library, it should declare that dependency). On systems without package managers, we could provide some form of "sub-platform" containing C libraries or a system for installing them, but then installing a Haskell system is no longer a one-step process.

Well, I'd hope that the stuff that's being built around _building_ HP (helper scripts / procedures for putting together binary installers on Mac and Win) is general enough so that it can be used to do a HP+ (or a number of installers) that includes different C lib bindings. In essence, that would result in a set of prepared Haskell packages for the platforms that lack a good package manager.

...

It's been a while since I was a regular Windows user, but it seemed then that bundling dependencies was the most common (only?) solution.

I don't know of any other way either. I just strongly oppose the idea that HP should take on the role of providing C lib bindings just because on some platforms it's hard to satisfy the C dependencies. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

Bulat Ziganshin

7:59 a.m.

New subject: Re[2]: Re: Thinking about what's missing in our library coverage

Hello Magnus, Wednesday, August 5, 2009, 11:37:23 AM, you wrote:

...

I don't know of any other way either. I just strongly oppose the idea that HP should take on the role of providing C lib bindings just because on some platforms it's hard to satisfy the C dependencies.

those some platfroms are 97% of all dowanloads and success on these platforms is the key to overall Haskell success. moreover, asd i understand the situation, lack of package manager on Windows was main motivation to establish HP - for unicies it's not really required -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Magnus Therning

8:49 a.m.

New subject: Re[2]: Re: Thinking about what's missing in our library coverage

On Wed, Aug 5, 2009 at 8:59 AM, Bulat Ziganshin wrote:

...

Hello Magnus,

Wednesday, August 5, 2009, 11:37:23 AM, you wrote:

...
I don't know of any other way either. I just strongly oppose the idea that HP should take on the role of providing C lib bindings just because on some platforms it's hard to satisfy the C dependencies.

those some platfroms are 97% of all dowanloads and success on these platforms is the key to overall Haskell success. moreover, asd i understand the situation, lack of package manager on Windows was main motivation to establish HP - for unicies it's not really required

80% of all internet-related statistics are made dubious ;-) I strongly doubt the "97% of all downloads" statement. However, that's not really what we are discussing here. This is the statement on the Haskell Platform page: "The Haskell Platform is a blessed library and tool suite for Haskell distilled from Hackage, along with installers for a wide variety of machines. The contents of the platform is specified here: Haskell: Batteries Included. "The platform saves you the task of picking and choosing the best Haskell libraries and tools to use for a task. Distro maintainers that support the Haskell Platform can be confident they're fully supporting Haskell as the developers intend it. Developers targetting the platform can be confident they have a trusted base of code to work with." The way _I_ read it, HP is a set of libraries that form a supplement to a Haskell compiler/interpreter. Developers can feel confident writing code against this set of libraries and it's the goal to make HP available on as many platforms as possible. I don't think that establishing HP was mainly motivated by the lack of a package manager for windows, I also don't think that HP is un-needed on Unices. AFAIU the motivation was to 1) separate the compiler/interpreter (especially GHC) from "base libraries", 2) to clearly communicate what Haskell packages a developer can expect to find on a "Haskell system", and 3) to provide users/developers with an easy route to setting up a "Haskell system" on different OSs. Difficulty to build a C dependency of a Haskell library should _not_ be a criterion used to decide whether the Haskell library goes into HP or not. Cabal is great for source distribution, but apparently there's a need for a binary packager, especially for Windows. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

Don Stewart

5:38 p.m.

New subject: Thinking about what's missing in our library coverage

bulat.ziganshin:

...

Hello Magnus,

Wednesday, August 5, 2009, 11:37:23 AM, you wrote:

...
I don't know of any other way either. I just strongly oppose the idea that HP should take on the role of providing C lib bindings just because on some platforms it's hard to satisfy the C dependencies.

those some platfroms are 97% of all dowanloads and success on these platforms is the key to overall Haskell success. moreover, asd i understand the situation, lack of package manager on Windows was main motivation to establish HP - for unicies it's not really required

The motivation was to have a high quality Haskell environment on every system. That the unicies would all agree on what they provide was "Haskell". Fixing up Windows was a nice side effect. -- Don

Bulat Ziganshin

4 Aug 4 Aug

4:31 p.m.

New subject: Thinking about what's missing in our library coverage

Hello John, Tuesday, August 4, 2009, 7:54:14 PM, you wrote:

...

methods other than Deflate." A better solution, perhaps, would be a binding to libzip.

it's hard to find feature list for libzip, but i suggest to look into 7zip library support. it supports lot of archive formats, including zip, rar, 7z, and for zip supports zip64, unicode filenames, aes encryption, bzip2/lzma. license is lgpl, API is COM-like that may be a hard part -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Jason Dagit

13 Aug 13 Aug

2:52 p.m.

New subject: Thinking about what's missing in our library coverage

On Mon, Aug 3, 2009 at 10:53 PM, Don Stewart wrote:

...

alexander.dunlap:

...
...
o pandoc — markdown, reStructuredText, HTML, LaTeX, ConTeXt,

Docbook, OpenDocument, ODT, RTF, MediaWiki, groff

No. Pandoc is too actively developed to go into the HP. It's also much more of an end-user application than a "standard library" - it's applications are not general enough to be included in the standard distribution.

One comment on your thoughtful post.

What role does having unique capabilities for the Haskell Platform play?

Our base library is already notable for having OpenGL support out of the box. Maybe markup/markdown formats (for example) would also help Haskell stand out from the crowd. A similar case would be gtk2hs out of the box (Python supplied Tcl guis).

I just thought of something I wanted to use Haskell for at work. It would be a tool used internally on windows and osx. I was thinking to myself, "Well, it would be nice if it had a GUI and the deps for building it were easy to satisfy." Naturally I looked at what packages the HP provides and I was disappointed to find out that other than OpenGL/GLUT and Win32 there are no GUI libraries provided. So a cross platfrom GUI library would be much appreciated. Whether that's wxHaskell, gtk2hs, or something else is not terribly important to me. On a side note, SDL support would be a nice addition to the OpenGL support. I think the other dependencies for what I have in mind are easily satisfied by the HP as it is. It would also be nice if we had some sort of web development platform as part of the HP. Those .NET folks have all these neat add-on libraries that just come bundled. Makes me jealous. Cabal-install makes things much easier overall so maybe I shouldn't complain... Thanks for the HP! Jason

Bryan O'Sullivan

4 Aug 4 Aug

4:56 p.m.

New subject: Thinking about what's missing in our library coverage

On Mon, Aug 3, 2009 at 10:40 PM, Alexander Dunlap < alexander.dunlap@gmail.com> wrote:

...

...
o unicode text [text] [text-icu] — packed, unicode text

This is essential, although I don't know if it is stable enough for the platform (?).

I'm doing some cleaning up of the APIs at the moment for usability purposes, but it would be really, really nice to have some help with testing, performance measurement, and tuning. The code is very clean and easy to understand :-)

Yitzchak Gale

5 Aug 5 Aug

1:28 p.m.

New subject: Thinking about what's missing in our library coverage

I agree with most of Alexander's many thoughtful comments about Don's list of potential additions to HP. But I disagree about pandoc. Alexander Dunlap wrote:

...

No. Pandoc is too actively developed to go into the HP.

It depends on the nature of the development. If the API is currently very unstable and is expected to stabilize soon, then wait a little bit. Otherwise, that is no excuse to exclude something worthwhile. Choose a well-tested numbered version and include it. Later, if we want to upgrade, just follow the usual deprecation-upgrade process. Umm - we do have a well-defined deprecation-upgrade process, don't we?

...

It's also much more of an end-user application than a "standard library"

pandoc provides an extensive library, and also a command-line app. Is it a policy that in such a case, we require the command-line app to be split off into a separate package before we can include it? I'm not sure that's so important, but if so, it should not be hard to do that for pandoc.

...

its applications are not general enough to be included in the standard distribution.

Text with markup is used in some way for almost every application. This library provides tools to convert between a wide variety of markup formats. Sounds pretty general to me. Other "batteries included" platforms contain various tools for processing markup that are far less general than pandoc. This is a place where Haskell can shine. So yes, pandoc should definitely be included in the platform. All that said, though, I will certainly agree that it is not currently in the top 5. Regards, Yitz

Tom Tobin

3:07 p.m.

New subject: Thinking about what's missing in our library coverage

On Wed, Aug 5, 2009 at 8:28 AM, Yitzchak Gale wrote:

...

I agree with most of Alexander's many thoughtful comments about Don's list of potential additions to HP. But I disagree about pandoc. [...] So yes, pandoc should definitely be included in the platform.

I should preface this by saying that while I'm an experienced Python programmer, I'm *very* new to Haskell. As I understand it, Pandoc is entirely under the GPL (not LGPL). I'd be very wary of accepting a GPL'd library as a blessed "standard" library, since it would be completely unusable for non-GPL projects. One of the nice things about the Python standard library is that you know it's liberally licensed; a programmer can feel free to use it for any project, whether proprietary or copyleft or otherwise. I don't think I'd feel comfortable using or recommending the Haskell Platform if "batteries included" came with such a serious caveat.

Yitzchak Gale

3:12 p.m.

New subject: Thinking about what's missing in our library coverage

Tom Tobin wrote:

...

As I understand it, Pandoc is entirely under the GPL (not LGPL).

Oh. That would be an issue, yes. Too bad. Thanks, Yitz

Colin Paul Adams

3:19 p.m.

New subject: Thinking about what's missing in our library coverage

...

...
...
...
...
"Tom" == Tom Tobin writes:

Tom> As I understand it, Pandoc is entirely under the GPL (not Tom> LGPL). I'd be very wary of accepting a GPL'd library as a I'd be very upset if pandoc weren't blessed. Tom> blessed "standard" library, since it would be completely Tom> unusable for non-GPL projects. This can surely be tackled by cabal, as it already has the license information. So if you were to specify you project has a BSD license, and it requires use of a library licensed under the GPL, then cabal configure should fail with an error message. Just because a library is blessed, doesn't mean you have to use it. -- Colin Adams Preston Lancashire

Tom Tobin

3:37 p.m.

New subject: Thinking about what's missing in our library coverage

On Wed, Aug 5, 2009 at 10:19 AM, Colin Paul Adams wrote:

...

Just because a library is blessed, doesn't mean you have to use it.

Then I'm not sure I understand the point of blessing it in a set of libraries that "saves you the task of picking and choosing the best Haskell libraries and tools to use for a task" if "task" (in the second mention) is limited to "developing GPL'd software". The "picking and choosing" problem immediately comes back for everyone else, leaving the platform with second-class users who are forced to evaluate the libraries to make sure they're legally compatible — defeating the purpose of the platform.

...

This can surely be tackled by cabal, as it already has the license information.

I don't see this as a real solution; why would a package be added to the platform in the first place if a large proportion of developers couldn't make use of it?

Colin Paul Adams

3:46 p.m.

New subject: Thinking about what's missing in our library coverage

...

...
...
...
...
"Tom" == Tom Tobin writes:

>> This can surely be tackled by cabal, as it already has the >> license information. Tom> I don't see this as a real solution; why would a package be It should be done anyway, irrespective of the platform. Tom> added to the platform in the first place if a large Tom> proportion of developers couldn't make use of it? Anyone can make use of it. You may choose not to (or your boss may choose for you), but that doesn't mean you can't. -- Colin Adams Preston Lancashire

Tom Tobin

4:03 p.m.

New subject: Thinking about what's missing in our library coverage

On Wed, Aug 5, 2009 at 10:46 AM, Colin Paul Adams wrote:

...

...
...
...
...
...
"Tom" == Tom Tobin writes:

>> This can surely be tackled by cabal, as it already has the >> license information.

Tom> I don't see this as a real solution; why would a package be

It should be done anyway, irrespective of the platform.

Yes, that would be handy option for cabal-install in general.

...

Tom> added to the platform in the first place if a large Tom> proportion of developers couldn't make use of it?

Anyone can make use of it. You may choose not to (or your boss may choose for you), but that doesn't mean you can't.

The benefit of a standard library is that you can say "I need a library to handle X" and if a library addressing X is in the standard library, you're set. If you then need to worry about the GPL — and this is a reality that can't be written off as a mere "choice" — why bother with the platform in the first place? Non-GPL developers would be better off sticking with hackage in that case.

John A. De Goes

4:33 p.m.

New subject: Thinking about what's missing in our library coverage

Tom is exactly right here. GPL is the kiss of death in the commercial world. Haskell Platform exists in part to encourage industry use of Haskell -- and to encourage "braindead" use of blessed libraries. GPL libraries have no place in HP. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Aug 5, 2009, at 9:03 AM, Tom Tobin wrote:

...

On Wed, Aug 5, 2009 at 10:46 AM, Colin Paul Adams wrote:

...
...
...
...
...
> "Tom" == Tom Tobin writes:

...
...
This can surely be tackled by cabal, as it already has the license information.

Tom> I don't see this as a real solution; why would a package be

It should be done anyway, irrespective of the platform.

Yes, that would be handy option for cabal-install in general.

...
Tom> added to the platform in the first place if a large Tom> proportion of developers couldn't make use of it?

Anyone can make use of it. You may choose not to (or your boss may choose for you), but that doesn't mean you can't.

The benefit of a standard library is that you can say "I need a library to handle X" and if a library addressing X is in the standard library, you're set. If you then need to worry about the GPL — and this is a reality that can't be written off as a mere "choice" — why bother with the platform in the first place? Non-GPL developers would be better off sticking with hackage in that case. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Robin Green

4:49 p.m.

New subject: Thinking about what's missing in our library coverage

And even if you don't agree with that, it would likely lead to accidental use of GPL software in proprietary software, which is not a good thing. -- Robin On Wed, 5 Aug 2009 09:33:34 -0700 "John A. De Goes" wrote:

...

Tom is exactly right here. GPL is the kiss of death in the commercial world. Haskell Platform exists in part to encourage industry use of Haskell -- and to encourage "braindead" use of blessed libraries. GPL libraries have no place in HP.

Regards,

John A. De Goes N-Brain, Inc. The Evolution of Collaboration

http://www.n-brain.net | 877-376-2724 x 101

On Aug 5, 2009, at 9:03 AM, Tom Tobin wrote:

...
On Wed, Aug 5, 2009 at 10:46 AM, Colin Paul Adams wrote:

...
...
...
...
>> "Tom" == Tom Tobin writes:

...
...
This can surely be tackled by cabal, as it already has the license information.

Tom> I don't see this as a real solution; why would a package be

It should be done anyway, irrespective of the platform.

Yes, that would be handy option for cabal-install in general.

...
Tom> added to the platform in the first place if a large Tom> proportion of developers couldn't make use of it?

Anyone can make use of it. You may choose not to (or your boss may choose for you), but that doesn't mean you can't.

The benefit of a standard library is that you can say "I need a library to handle X" and if a library addressing X is in the standard library, you're set. If you then need to worry about the GPL — and this is a reality that can't be written off as a mere "choice" — why bother with the platform in the first place? Non-GPL developers would be better off sticking with hackage in that case. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Robin

Robin Green

4:46 p.m.

New subject: Thinking about what's missing in our library coverage

On Wed, 5 Aug 2009 11:03:55 -0500 Tom Tobin wrote:

...

On Wed, Aug 5, 2009 at 10:46 AM, Colin Paul Adams wrote:

...
...
...
...
...
> "Tom" == Tom Tobin writes:

>> This can surely be tackled by cabal, as it already has the >> license information.

Tom> I don't see this as a real solution; why would a package be

It should be done anyway, irrespective of the platform.

Yes, that would be handy option for cabal-install in general.

My feature request for this is here: http://hackage.haskell.org/trac/hackage/ticket/481 where you can read a reply by Duncan listing some problems with this idea. -- Robin

Don Stewart

5:39 p.m.

New subject: Thinking about what's missing in our library coverage

gale:

...

Other "batteries included" platforms contain various tools for processing markup that are far less general than pandoc. This is a place where Haskell can shine.

So yes, pandoc should definitely be included in the platform. All that said, though, I will certainly agree that it is not currently in the top 5.

I agree with this. We would shine, but maybe not for the first cut. Especially since the maintainer has requested this. Note also: pandoc is GPL -- Don

Johan Tibell

7 Aug 7 Aug

11:40 a.m.

New subject: Thinking about what's missing in our library coverage

On Tue, Aug 4, 2009 at 7:40 AM, Alexander Dunlap wrote:

...

Interface unification would help. Especially network-bytestring seems to be too ad-hoc for me - it would probably be better to put ByteString support into the regular Network library....

It's my intention to get it merged into network now when I'm the maintainer of both libraries. There's an open ticket for this task and I will propose the merge on the libraries mailing list shortly. Cheers, Johan

5809

Age (days ago)

5818

Last active (days ago)

List overview

Download

25 comments

14 participants

participants (14)

Alexander Dunlap
Bryan O'Sullivan
Bulat Ziganshin
Colin Paul Adams
Don Stewart
Jason Dagit
Johan Tibell
John A. De Goes
John MacFarlane
Magnus Therning
Max Rabkin
Robin Green
Tom Tobin
Yitzchak Gale