Re: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
On Mon, Aug 3, 2009 at 10:53 PM, Don Stewart d...@galois.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
On Tue, Aug 4, 2009 at 7:40 AM, Alexander Dunlapalexander.dun...@gmail.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
On Tue, Aug 4, 2009 at 11:05 PM, Max Rabkinmax.rab...@gmail.com wrote: On Tue, Aug 4, 2009 at 11:56 PM, Magnus Therningmag...@therning.org 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] 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, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
On Wed, Aug 5, 2009 at 8:59 AM, Bulat Ziganshinbulat.zigans...@gmail.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
Tom == Tom Tobin korp...@korpios.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
On Wed, Aug 5, 2009 at 10:19 AM, Colin Paul Adamsco...@colina.demon.co.uk 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? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
Tom == Tom Tobin korp...@korpios.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
On Wed, Aug 5, 2009 at 10:46 AM, Colin Paul Adamsco...@colina.demon.co.uk wrote: Tom == Tom Tobin korp...@korpios.com 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
Re: [Haskell-cafe] Re: 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 Adamsco...@colina.demon.co.uk wrote: Tom == Tom Tobin korp...@korpios.com 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
Re: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
On Wed, 5 Aug 2009 11:03:55 -0500 Tom Tobin korp...@korpios.com wrote: On Wed, Aug 5, 2009 at 10:46 AM, Colin Paul Adamsco...@colina.demon.co.uk wrote: Tom == Tom Tobin korp...@korpios.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: 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 j...@n-brain.net 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 Adamsco...@colina.demon.co.uk wrote: Tom == Tom Tobin korp...@korpios.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
On Tue, Aug 4, 2009 at 4:54 PM, John MacFarlanej...@berkeley.edu 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
On Tue, Aug 4, 2009 at 6:13 PM, Magnus Therningmag...@therning.org 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: 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, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
On Mon, Aug 3, 2009 at 10:40 PM, Alexander Dunlap alexander.dun...@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 :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
Max Rabkin wrote: On Tue, Aug 4, 2009 at 6:13 PM, Magnus Therningmag...@therning.org 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 signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
On Tue, Aug 4, 2009 at 11:56 PM, Magnus Therningmag...@therning.org 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Thinking about what's missing in our library coverage
On Mon, Aug 3, 2009 at 4:44 PM, Don Stewartd...@galois.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
