Hi, It seems every time I look at hackage there is yet another stringy datatype. For lots of apps, the particular stringy datatype you use matters for performance but not algorithmic reasons. Perhaps this is a good time for someone to propose a stringy class? Matthew
Am Freitag, 6. März 2009 13:33 schrieb Matthew Pocock:
Hi,
It seems every time I look at hackage there is yet another stringy datatype. For lots of apps, the particular stringy datatype you use matters for performance but not algorithmic reasons. Perhaps this is a good time for someone to propose a stringy class?
Matthew
There is already the class IsString which was introduced for overloaded string literals. However, the name is terrible. No other Haskell class I know of has an “Is” at its beginning. Classes don’t name properties (IsNum, IsMonoid, Has…). Maybe you can also try to convince the masters of the IsString class to change the class name. My previous attempts through mailing list e-mails seemed to have no effect. :-( Best wishes, Wolfgang
2009/3/6 Wolfgang Jeltsch <g9ks157k@acme.softbase.org>:
Am Freitag, 6. März 2009 13:33 schrieb Matthew Pocock:
Hi,
It seems every time I look at hackage there is yet another stringy datatype. For lots of apps, the particular stringy datatype you use matters for performance but not algorithmic reasons. Perhaps this is a good time for someone to propose a stringy class?
Matthew
There is already the class IsString which was introduced for overloaded string literals.
However, the name is terrible. No other Haskell class I know of has an “Is” at its beginning. Classes don’t name properties (IsNum, IsMonoid, Has…).
LLVM bindings use it a lot... Cheers, Thu
I'd be more interested in a kitchen-sink "List" class. ByteString, ByteString.Lazy, Text, [a], and the pending Text.Lazy all support the basic operations of lists of a particular type. It'd be a fairly huge dictionary by the current API design of those however. Its just a reiteration of the classic "Collection" class example. The biggest problem is that it requires either MPTCs/fundeps or type aliases to make it work, which makes less progressive folks queasy about its inclusion as a standard library. On the other hand, if you're going that far, it'd be nice to factor out a superclass or two for things like lookup/insert functionality, so you can eliminate a major reason why Data.Map has to be imported qualified as well. -Edward Kmett On Fri, Mar 6, 2009 at 11:16 AM, minh thu <noteed@gmail.com> wrote:
2009/3/6 Wolfgang Jeltsch <g9ks157k@acme.softbase.org>:
Am Freitag, 6. März 2009 13:33 schrieb Matthew Pocock:
Hi,
It seems every time I look at hackage there is yet another stringy datatype. For lots of apps, the particular stringy datatype you use matters for performance but not algorithmic reasons. Perhaps this is a good time for someone to propose a stringy class?
Matthew
There is already the class IsString which was introduced for overloaded string literals.
However, the name is terrible. No other Haskell class I know of has an “Is” at its beginning. Classes don’t name properties (IsNum, IsMonoid, Has…).
LLVM bindings use it a lot...
Cheers, Thu _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
I'd be more interested in a kitchen-sink "List" class. ByteString, ByteString.Lazy, Text, [a], and the pending Text.Lazy all support the basic operations of lists of a particular type. It'd be a fairly huge dictionary by the current API design of those however. Its just a reiteration of the classic "Collection" class example.
Like this? http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ListLike Sean
Sean Leather schrieb:
Like this?
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ListLike
Indeed, a class StringLike is included there as well. Why not take or improve that one? Till
On 2009 Mar 6, at 11:13, Wolfgang Jeltsch wrote:
Am Freitag, 6. März 2009 13:33 schrieb Matthew Pocock:
It seems every time I look at hackage there is yet another stringy datatype. For lots of apps, the particular stringy datatype you use matters for performance but not algorithmic reasons. Perhaps this is a good time for someone to propose a stringy class?
There is already the class IsString which was introduced for overloaded string literals.
However, the name is terrible. No other Haskell class I know of has an “Is” at its beginning. Classes don’t name properties (IsNum, IsMonoid, Has…).
But their proper names were available. "String" is already taken for a concrete type, which complicates things; "IsString" was the simplest answer (and possibly avoided bikeshedding by being the answer nobody liked :)
Maybe you can also try to convince the masters of the IsString class to change the class name. My previous attempts through mailing list e-mails seemed to have no effect. :-(
I think the problem here is you need to get buy-in from everyone involved, which includes libraries@ (String), ghc (IsString is recognized in order to enable string overloading), ByteString, and potentially anyone who uses any of the above. That said, if you want to officially propose it you need to read up on how to properly propose such changes to libraries@haskell.org. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
Matthew Pocock wrote:
It seems every time I look at hackage there is yet another stringy datatype. For lots of apps, the particular stringy datatype you use matters for performance but not algorithmic reasons. Perhaps this is a good time for someone to propose a stringy class?
Not likely. I did define my own (private) class for regular expressions, to abstract over String, the ByteStrings, and Seq Char. But it is used in one place and is a wart that should be removed. The simple task of looping over the contents of a String (once, forward) is quite different from a Strict ByteString (using an index and a lookup). This means for decent efficiency I need two copies of my code, hand specialized to each case. "tail" or "(x:xs)" : very efficient for String (no allocation) "tail" or "uncons" : not efficient for ByteString (allocation, might as well convert to [Char] And indexing by Int is O(n) for String and O(1) for ByteString. So there are few algorithm that can access both efficiently.
What about AString or AnyString?
-----Original Message----- From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Chris Kuklewicz Sent: Friday, March 06, 2009 8:17 PM To: Matthew Pocock Cc: haskell@haskell.org Subject: Re: [Haskell] string type class
Matthew Pocock wrote:
It seems every time I look at hackage there is yet another stringy datatype. For lots of apps, the particular stringy datatype you use matters for performance but not algorithmic reasons. Perhaps this is a good time for someone to propose a stringy class?
Not likely.
I did define my own (private) class for regular expressions, to abstract over String, the ByteStrings, and Seq Char. But it is used in one place and is a wart that should be removed.
The simple task of looping over the contents of a String (once, forward) is quite different from a Strict ByteString (using an index and a lookup).
This means for decent efficiency I need two copies of my code, hand specialized to each case.
"tail" or "(x:xs)" : very efficient for String (no allocation) "tail" or "uncons" : not efficient for ByteString (allocation, might as well convert to [Char]
And indexing by Int is O(n) for String and O(1) for ByteString.
So there are few algorithm that can access both efficiently.
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
participants (9)
-
Brandon S. Allbery KF8NH -
Chris Kuklewicz -
Edward Kmett -
Matthew Pocock -
minh thu -
Peter Verswyvelen -
Sean Leather -
Till Mossakowski -
Wolfgang Jeltsch