Thinking about what's missing in our library coverage

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
78 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Thinking about what's missing in our library coverage

Don Stewart-2

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 binary formatting [binary] — lazy binary parsing/serialising
          o pcre regexes [pcre-light] [regex-pcre] — what’s our best regex lib?
          o unicode text [text] [text-icu] — packed, unicode text
          o codecs/encodings — encodings?
    * Data types
          o higher dimensional arrays [hmatrix]
          o bloomfilter — bloomfilters
          o bytestring-tries — IntMap for ByteStrings
          o dlist — difference lists
          o numbers — expanded number types
    * text
          o attoparsec (simple, bytestring parsing)
          o polyparse
          o csv parsing
          o pandoc — markdown, reStructuredText, HTML, LaTeX, ConTeXt, Docbook, OpenDocument, ODT, RTF, MediaWiki, groff
    * math and numerics
          o blas — BLAS
          o cmath — C math functions
          o dimensional — physical dimensions
          o fftw
          o mersenne-random — fast randoms
    * persistance
          o anydbm?
          o sqlite3
          o hdbc
    * compression
          o bzip2
          o zip
          o tar
    * file formats
          o csv
          o config parser
    * crypto
          o hmac, md5, sha, hashing
    * systems
          o getopt
          o logging
          o termio
          o editline
          o mmap
    * 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
    * Multimedia
          o colour
    * Internationalization
          o gettext
          o locale
          o i18n
    * GUIs
          o gtk2hs
    * Development
          o hscolour
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Ian Lynagh
On Mon, Aug 03, 2009 at 04:44:32PM -0700, Donald Bruce Stewart wrote:
>
> How would you identify the top, say, 5 libs to add?

I would not look for libs to add. I would wait for people to come and
tell me that they think that particular libs are worthy of addition, and
then decide whether or not I agree.


Thanks
Ian

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Don Stewart-2
igloo:
> On Mon, Aug 03, 2009 at 04:44:32PM -0700, Donald Bruce Stewart wrote:
> >
> > How would you identify the top, say, 5 libs to add?
>
> I would not look for libs to add. I would wait for people to come and
> tell me that they think that particular libs are worthy of addition, and
> then decide whether or not I agree.

That's fine. I'm just trying to get a sense of what people will be
proposing, and why.

Is this an 'identify the champion' model? We await a champion to propose
things?

-- Don
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Felipe Lessa
In reply to this post by Don Stewart-2
On Mon, Aug 03, 2009 at 04:44:32PM -0700, Don Stewart wrote:
>     * compression
>           o bzip2
>           o zip
>           o tar

These seem nice.

>     * systems
>           o getopt
>           o editline

These, too.

>     * GUIs
>           o gtk2hs

Now this looks like trouble :).  I mean, I would love to know
that Gtk2Hs is installed everywhere, but IMHO it would put a
great burden to the platform.  Would it just bundle the whole
Gtk+ inside the instaler?  Hmmm...

--
Felipe.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Bulat Ziganshin-2
Hello Felipe,

Tuesday, August 4, 2009, 5:42:21 AM, you wrote:

>>           o gtk2hs

> Now this looks like trouble :).  I mean, I would love to know
> that Gtk2Hs is installed everywhere, but IMHO it would put a
> great burden to the platform.  Would it just bundle the whole
> Gtk+ inside the instaler?  Hmmm...

one posible solution to this problem would be to split HP into two
editions - basic one should be kept small and simple, even smaller
than old GHC distros (i.e. minus opengl-like stuff, with only "core"
libraries remaining). while batteries included distro should grow, its
main goal - provide one-step installer of whole Haskell world


--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Krasimir Angelov-2
In reply to this post by Don Stewart-2
On 8/4/09, Don Stewart <[hidden email]> wrote:
>    * systems
>          o getopt
>          o logging
>          o termio
>          o editline
>          o mmap

editline is known to have problem with Unicode. Why not Haskeline?
Even readline is better than editline.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Simon Marlow-7
In reply to this post by Ian Lynagh
On 04/08/2009 00:59, Ian Lynagh wrote:
> On Mon, Aug 03, 2009 at 04:44:32PM -0700, Donald Bruce Stewart wrote:
>>
>> How would you identify the top, say, 5 libs to add?
>
> I would not look for libs to add. I would wait for people to come and
> tell me that they think that particular libs are worthy of addition, and
> then decide whether or not I agree.

Ok, to kick things off then, I propose the following:

Add

  * binary
  * getopt
  * gtk2hs

Also

  * keep an eye on text.  We certainly want it, but it's
    a young package and there's no text I/O yet.
  * decide which regex package(s) we want
  * remove html? (we have xhtml)
  * replace haskell-src with haskell-src-exts
  * remove packedstring

Cheers,
        Simon
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Gwern Branwen
On Tue, Aug 4, 2009 at 7:02 AM, Simon Marlow<[hidden email]> wrote:
> Add
>
>  * binary
>  * getopt
>  * gtk2hs

A definite yes to binary and getopt; but gtk2hs? I don't trust its longevity or maintenance, and as other people have pointed out, it will make the platform harder to support. As well, we risk holding back the platform - hasn't gtk2hs lagged GHC releases in the past? (I seem to remember some of the lags being quite lengthy.)

> Also
>
>  * keep an eye on text.  We certainly want it, but it's
>   a young package and there's no text I/O yet.
>  * decide which regex package(s) we want
>  * remove html? (we have xhtml)
>  * replace haskell-src with haskell-src-exts
>  * remove packedstring

Absolutely. I thought we had already done this - didn't TH's unnecessary use of packedstring get removed a while ago?

> Cheers,
>        Simon

--
gwern
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Simon Marlow-7
On 04/08/2009 12:07, Gwern Branwen wrote:

> On Tue, Aug 4, 2009 at 7:02 AM, Simon Marlow<[hidden email]> wrote:
>> Add
>>
>>  * binary
>>  * getopt
>>  * gtk2hs
>
> A definite yes to binary and getopt; but gtk2hs? I don't trust its
> longevity or maintenance, and as other people have pointed out, it will
> make the platform harder to support. As well, we risk holding back the
> platform - hasn't gtk2hs lagged GHC releases in the past? (I seem to
> remember some of the lags being quite lengthy.)

Adding gtk2hs would be a bold step, no doubt about it.  By proposing it
I'm hoping to force the issues to the surface: is gtk2hs the GUI lib we
want to recommend, or standardise on?  If it is, and it has maintenance
issues, then those need to be addressed.  As far as I'm aware, gtk2hs is
the only plausible option for serious GUI development in Haskell at the
moment.

By bringing gtk2hs into the platform, we would be giving the gtk2hs
maintainers a helpful boost; they'd get more testing for one thing.

>> Also
>>
>>  * keep an eye on text.  We certainly want it, but it's
>>   a young package and there's no text I/O yet.
>>  * decide which regex package(s) we want
>>  * remove html? (we have xhtml)
>>  * replace haskell-src with haskell-src-exts
>>  * remove packedstring
>
> Absolutely. I thought we had already done this - didn't TH's unnecessary
> use of packedstring get removed a while ago?

Not in the version of TH shipping with GHC 6.10.x, but it will be gone
in GHC 6.12.

Cheers,
        Simon


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Sittampalam, Ganesh
Simon Marlow wrote:

> By bringing gtk2hs into the platform, we would be giving the gtk2hs
> maintainers a helpful boost; they'd get more testing for one thing.

I think that should explicitly not be a reason to bring things into the
platform.

Ganesh

===============================================================================
 Please access the attached hyperlink for an important electronic communications disclaimer:
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 ===============================================================================
 
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Malcolm Wallace
In reply to this post by Simon Marlow-7
> As far as I'm aware, gtk2hs is the only plausible option for serious  
> GUI development in Haskell at the moment.

I have used both wxHaskell and gtk2hs, and they are both perfectly  
easy to install, and both are entirely adequate for serious GUI  
development.  Just wanted to clear up any fear, uncertainty, or doubt  
about wx.

Regards,
     Malcolm

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Axel Simon-2
In reply to this post by Sittampalam, Ganesh
Hi Simon et al.,

On Aug 4, 2009, at 13:57, Sittampalam, Ganesh wrote:

> Simon Marlow wrote:
>
>> By bringing gtk2hs into the platform, we would be giving the gtk2hs
>> maintainers a helpful boost; they'd get more testing for one thing.
>
> I think that should explicitly not be a reason to bring things into  
> the
> platform.


Bringing Gtk2Hs into the platform is certainly desirable. During the  
last one or two years, the  amount of users has grown steadily which  
is nice. However, Pete and my time is rather limited and is often  
being used up by installation issues and questions that could be  
answered with better documentation. Thus, it would be desirable to  
bring Gtk2Hs into the platform because it would force us to simplify  
installation and documentation.

For the former part, I wonder if cabalization is important for  
Gtk2Hs. A cabalized version of Gtk2Hs would allow people to use Cairo  
and Pango to create PDF documents without the need to install the GUI  
parts of the library. On the contrary, if Gtk2Hs is shipped with the  
platform, then all libraries are available anyway and cabalization  
might not be as important.

My question: how important is cabalization for a package that wants  
to be part of the platform?

Axel.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Simon Marlow-7
In reply to this post by Sittampalam, Ganesh
On 04/08/2009 12:57, Sittampalam, Ganesh wrote:
> Simon Marlow wrote:
>
>> By bringing gtk2hs into the platform, we would be giving the gtk2hs
>> maintainers a helpful boost; they'd get more testing for one thing.
>
> I think that should explicitly not be a reason to bring things into the
> platform.

*grin* absolutely :)

However, I don't think the platform should just swim around with its
mouth open waiting for tasty packages to come along.  Sometimes we need
to make strategic decisions about what functionality is most important.

Cheers,
   Simon
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Yitzchak Gale
In reply to this post by Don Stewart-2
Don Stewart wrote:
> The following things were missing from the current Platform. There are many.
> How would you identify the top, say, 5 libs to add?

XML support is missing from your list. That is definitely part
of every modern "batteries included" platform, and it should
be high on our list. We have a number of excellent and mature
packages in this category.

Regards,
Yitz
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Sittampalam, Ganesh
In reply to this post by Simon Marlow-7
Simon Marlow wrote:

> On 04/08/2009 12:57, Sittampalam, Ganesh wrote:
>> Simon Marlow wrote:
>>
>>> By bringing gtk2hs into the platform, we would be giving the gtk2hs
>>> maintainers a helpful boost; they'd get more testing for one thing.
>>
>> I think that should explicitly not be a reason to bring things into
>> the platform.
>
> *grin* absolutely :)
>
> However, I don't think the platform should just swim around with its
> mouth open waiting for tasty packages to come along.  Sometimes we
> need to make strategic decisions about what functionality is most
> important.  

Agreed, and with this in mind perhaps packages should be conditionally
accepted, with a defined set of improvements leading to automatic entry.
This would allow the platform to drive priorities without dumping things
into it half-done.

Cheers,

Ganesh

===============================================================================
 Please access the attached hyperlink for an important electronic communications disclaimer:
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 ===============================================================================
 
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Ian Lynagh
In reply to this post by Axel Simon-2
On Tue, Aug 04, 2009 at 02:21:11PM +0200, Axel Simon wrote:
>
> My question: how important is cabalization for a package that wants to be
> part of the platform?

I think it's important. It means that:

* It can be built and installed in a regular way when creating the
  binary platform installers, without needing special case code

* It can be built and installed in a regular way in Linux distros etc,
  so it does not place an extra burden on distro maintainers trying to
  support the platform

* The platform can be installed with just cabal-install (although you
  will also need to install the C libraries etc)

* People who want to test newer versions that are intended to come with
  a future platform release can easily do so


Thanks
Ian

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Jeremy O'Donoghue
In reply to this post by Malcolm Wallace
2009/8/4 Malcolm Wallace <[hidden email]>:
>> As far as I'm aware, gtk2hs is the only plausible option for serious GUI
>> development in Haskell at the moment.
>
> I have used both wxHaskell and gtk2hs, and they are both perfectly easy to
> install, and both are entirely adequate for serious GUI development.  Just
> wanted to clear up any fear, uncertainty, or doubt about wx.


Disclaimer: I'm a wxHaskell maintainer.

Thanks for the vote, Malcolm. I use wxHaskell in some fairly extensive
GUI developments, and it's stable and functional.

On a more serious note (and one which applies equally to wxHaskell,
BTW), I think the Haskell Platform should consistently use a single
license, as to do otherwise heavily complicates matters for the user.

I believe that most/all of the libraries in today's platform are BSD (or
other very liberal license). Gtk2Hs brings LGPL into the mix, and
wxHaskell would, similarly, bring the wxWidgets license (LGPL with
binary exception, basically) into the mix.

As a Haskell Platform user, I really need the assurance that the
licensing situation is straightforward - especially if I'm to promote
Haskell at work  :-)

My vote would be that non-BSD/MIT license automatically excludes a
library from inclusion, even though it would exclude my own project.

Regards
Jeremy
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Don Stewart-2
In reply to this post by Simon Marlow-7
marlowsd:

> On 04/08/2009 12:57, Sittampalam, Ganesh wrote:
>> Simon Marlow wrote:
>>
>>> By bringing gtk2hs into the platform, we would be giving the gtk2hs
>>> maintainers a helpful boost; they'd get more testing for one thing.
>>
>> I think that should explicitly not be a reason to bring things into the
>> platform.
>
> *grin* absolutely :)
>
> However, I don't think the platform should just swim around with its  
> mouth open waiting for tasty packages to come along.  Sometimes we need  
> to make strategic decisions about what functionality is most important.

I agree with this. There are broader adoption issues we're trying to
achieve in this process, after all, and having a better base lib than
anyone else helps that.

-- Don
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

John Lato-2
In reply to this post by Don Stewart-2
> Date: Tue, 4 Aug 2009 15:13:16 +0100
> From: "Jeremy O'Donoghue" <[hidden email]>
>
> My vote would be that non-BSD/MIT license automatically excludes a
> library from inclusion, even though it would exclude my own project.
>

+1

John Lato
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

wren romano-2
In reply to this post by Don Stewart-2
Don Stewart wrote:
>           o bytestring-trie — IntMap for ByteStrings
>           o dlist — difference lists


Well, if we're looking for a champion, I suggest these two should be
added. Both serve demonstrated needs, both are easy to support, and both
are reinvented over and over again. Because of that reinvention alone,
it'd be nice to canonize a library in order to minimize wasted efforts.

(If anyone has complaints about bytestring-trie I'd be more than happy
to hear of and address them.)

--
Live well,
~wren
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
1234