String != [Char]
greg at gregweber.info
Thu Mar 22 22:49:40 CET 2012
I am not trying to win an argument with anyone. Just trying to do what
is best for the community. Many others here have a better grasp of the
issue than me and can help answer questions and come up with a
I am also not saying this proposal is done. A lot of thought and work
is needed to ensure it can be implemented as smoothly as possible. It
does seem though that everyone thinks it is a good proposal.
On Thu, Mar 22, 2012 at 2:06 PM, ARJANEN Loïc Jean David
<arjanen.loic at gmail.com> wrote:
> Le 22/03/2012 04:29, Greg Weber a écrit :
>> This proposal seems fairly uncontroversial at the moment. I would
>> really like it if someone more familiar with the proposal process can
>> take this proposal up and help make sure it gets in the next batch. I
>> can't even figure out how to create a wiki page for the proposal right
>> now :)
> Well, this proposal seems uncontroversial because we didn't arrive to the
> difficult part: what operations should we define on this String type for it
> to be useful.
> Because with only this proposal as it stands now (String defined as an
> implementation-defined newtype, a typeclass defined for conversion from/to
> String and [Char] as an instance of this typeclass), we're in a worse
> situation than before: not only String became useless given there is no
> operations defined on it, the only mean we have to portably work with it is
> to translate it to [Char] before doing anything.
> So now, the fun part begins...what operations should String support ? I
> propose obtaining the length of a String, taking a substring of a given size
> beginning at a given index, taking the character at index i in a String,
> concatenation, converting a string to upper/lower case and determining if a
> string is contained in/a prefix/a suffix of another.
> I am sure I am forgetting some useful operations and some operations I said
> are better placed in the typeclass or in a typeclass instance or are
> particular cases of general operations we should define rather than the
> particular cases. So, what are the operations we should define according to
> you ?
> ARJANEN Loïc
> Haskell-prime mailing list
> Haskell-prime at haskell.org
More information about the Haskell-prime