I think it's time that string literals got overloaded just like numeric literals. There are several reasons for this. One reason is the new fast string libraries. They are great, but string literals don't work; you need to pack them first. Another reason is the increasing use of Haskell for DSELs. In a DSEL you might want string literals to have a different type than the ordinary String. I have not implemented anything yet, but I would like to see something along the lines of the following: class IsString s where fromString :: String -> s instance IsString String where fromString = id The instance declaration is not allowed in Haskell-98, but it can be rewritten as class IsChar c where -- Make this class local to it's defining module fromChar :: Char -> c instance IsChar Char where fromChar = id instance (IsChar c) => IsString [c] where fromString = map fromChar And, like with numeric literals, any string literal will then have an implicit fromString insert to make the right conversion. My guess is that the defaulting mechanism needs to be extended to default to the String type as well, or we'll get some ambiguous expressions. Any thoughts? -- Lennart
On Fri, Nov 10, 2006 at 10:49:15PM -0500, Lennart Augustsson wrote:
Any thoughts?
what about pattern matching?
class IsString s where fromString :: String -> s
class IsString s => EqString s where eqString :: String -> s -> Bool
another posibillity would be for pattern matching to add an Eq constraint along with a IsString one on any pattern match of a string constant. I would very strongly prefer not to make Eq a superclass of IsString in any case. Just have a separate EqString class or pass around the Eq and IsString contexts separately. John -- John Meacham - ⑆repetae.net⑆john⑈
john:
On Fri, Nov 10, 2006 at 10:49:15PM -0500, Lennart Augustsson wrote:
Any thoughts?
what about pattern matching?
Yes, pattern matching is the issue that occurs to me too. While string literals :: ByteString would be nice (and other magic encoded in string literals, I guess), what is the story for pattern matching on strings based on non-inductive types like arrays? -- Don
Pattern matching would work like pattern matching with numeric literals does. You'll have to use equality comparison. To pattern match the string type would have to be in Eq as well. -- Lennart On Nov 10, 2006, at 23:33 , Donald Bruce Stewart wrote:
john:
On Fri, Nov 10, 2006 at 10:49:15PM -0500, Lennart Augustsson wrote:
Any thoughts?
what about pattern matching?
Yes, pattern matching is the issue that occurs to me too. While string literals :: ByteString would be nice (and other magic encoded in string literals, I guess), what is the story for pattern matching on strings based on non-inductive types like arrays?
-- Don _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
what about pattern matching?
Yes, pattern matching is the issue that occurs to me too. While string literals :: ByteString would be nice (and other magic encoded in string literals, I guess), what is the story for pattern matching on strings based on non-inductive types like arrays?
Pattern matching would work like pattern matching with numeric literals does. You'll have to use equality comparison. To pattern match the string type would have to be in Eq as well.
Mh, that's a showcase for Views. Something like view IsString a => String of a where ... That is, one has an already existing type that serves as a view for another one. Perhaps, Views should be more like class declarations with asssociated constructors class IsString a where [] :: a (:) :: Char -> a -> a Very similar to the new (G)ADT syntax and some kind of polymorphic variants with "virtual" constructors, isn't it? Anyway, the pattern guard approach would be to *not* allow string literals in pattern matches: patty bs | "pattern string" == bs = flip id id . flip id I think it's very unfair not to have general Views when now both polymorphic integers and string literals are to be allowed in pattern matching. Regards, apfelmus
Hello Donald, Saturday, November 11, 2006, 7:33:48 AM, you wrote:
Yes, pattern matching is the issue that occurs to me too. While string literals :: ByteString would be nice (and other magic encoded in string literals, I guess), what is the story for pattern matching on strings based on non-inductive types like arrays?
it's my day :) i'm regularly propose to pass list syntax to the special class which should define methods for building and analyzing data in head/tail way: class ListLike ce e | ce->e where -- Construction empty :: ce cons :: c -> ce -> ce -- Analyzing null :: ce -> Bool head :: ce -> e tail :: ce -> ce and then the following definition: trim (' ':xs) = trim xs trim xs = xs would imply the following type constraints: trim :: (ListLike ce Char, Eq Char) => ce -> ce -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Hello Lennart, Saturday, November 11, 2006, 6:49:15 AM, you wrote:
class IsString s where fromString :: String -> s
My guess is that the defaulting mechanism needs to be extended to default to the String type as well,
imho, it is MUST BE. this will allow to became ByteString and any other alternative string implementation a first-class Haskell citizen btw, String class is regularly debated and even implemented in fps-soc project where it includes a lot of common string functionality. just a head of this class: class (Eq s) => Stringable s where -- Introducing and eliminating -- | The empty string. empty :: s -- | Create a string containing a single 'Char'. singleton :: Char -> s -- | Convert a string into a standard Haskell 'String'. toList :: s -> [Char] toList = foldr (:) [] ........................ this may be disputed as part of library reorganization -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
To follow up on my own post. I implemented the overloaded strings last night and it seems to work pretty well. I've not done anything about defaulting yet. I don't know how much of a problem this will be in practice. On Nov 10, 2006, at 22:49 , Lennart Augustsson wrote:
I think it's time that string literals got overloaded just like numeric literals. There are several reasons for this. One reason is the new fast string libraries. They are great, but string literals don't work; you need to pack them first. Another reason is the increasing use of Haskell for DSELs. In a DSEL you might want string literals to have a different type than the ordinary String.
I have not implemented anything yet, but I would like to see something along the lines of the following:
class IsString s where fromString :: String -> s instance IsString String where fromString = id
The instance declaration is not allowed in Haskell-98, but it can be rewritten as class IsChar c where -- Make this class local to it's defining module fromChar :: Char -> c instance IsChar Char where fromChar = id instance (IsChar c) => IsString [c] where fromString = map fromChar
And, like with numeric literals, any string literal will then have an implicit fromString insert to make the right conversion.
My guess is that the defaulting mechanism needs to be extended to default to the String type as well, or we'll get some ambiguous expressions.
Any thoughts?
-- Lennart
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
In my experience I've seen more requests for overloaded *Boolean* literals than strings. In a Fran context, for example. Simon | -----Original Message----- | From: haskell-prime-bounces@haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of | Lennart Augustsson | Sent: 11 November 2006 03:49 | To: Haskell Prime | Subject: String literals | | I think it's time that string literals got overloaded just like | numeric literals. There are several reasons for this. One reason is | the new fast string libraries. They are great, but string literals | don't work; you need to pack them first. Another reason is the | increasing use of Haskell for DSELs. In a DSEL you might want string | literals to have a different type than the ordinary String. | | I have not implemented anything yet, but I would like to see | something along the lines of the following: | | class IsString s where | fromString :: String -> s | instance IsString String where | fromString = id | | The instance declaration is not allowed in Haskell-98, but it can be | rewritten as | class IsChar c where -- Make this class local to it's defining module | fromChar :: Char -> c | instance IsChar Char where | fromChar = id | instance (IsChar c) => IsString [c] where | fromString = map fromChar | | And, like with numeric literals, any string literal will then have an | implicit fromString insert to make the right conversion. | | My guess is that the defaulting mechanism needs to be extended to | default to the String type as well, or we'll get some ambiguous | expressions. | | Any thoughts? | | -- Lennart | | _______________________________________________ | Haskell-prime mailing list | Haskell-prime@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-prime
Hello Simon, Monday, November 13, 2006, 8:27:08 PM, you wrote:
In my experience I've seen more requests for overloaded *Boolean* literals than strings. In a Fran context, for example.
what you mean by this? а few days ago i've published in cafe small lib that allows to write things like ("str" && 0 || 1) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
But "if" is a keyword hardwired to work with Bool. You can't write if "str" then 0 else 1. This makes your solution seem like an add-on. I suppose that if haskell' added a Boolean class, it presumably would translate if/then/else to make use of it, so the above would start working just by adding instance Boolean String. Dan Bulat Ziganshin wrote:
Hello Simon,
Monday, November 13, 2006, 8:27:08 PM, you wrote:
In my experience I've seen more requests for overloaded *Boolean* literals than strings. In a Fran context, for example.
what you mean by this? а few days ago i've published in cafe small lib that allows to write things like ("str" && 0 || 1)
Oh, I'll take booleans too! But those are easier to fudge with the existing prelude (which I have). On Nov 13, 2006, at 12:27 , Simon Peyton-Jones wrote:
In my experience I've seen more requests for overloaded *Boolean* literals than strings. In a Fran context, for example.
Simon
| -----Original Message----- | From: haskell-prime-bounces@haskell.org [mailto:haskell-prime- bounces@haskell.org] On Behalf Of | Lennart Augustsson | Sent: 11 November 2006 03:49 | To: Haskell Prime | Subject: String literals | | I think it's time that string literals got overloaded just like | numeric literals. There are several reasons for this. One reason is | the new fast string libraries. They are great, but string literals | don't work; you need to pack them first. Another reason is the | increasing use of Haskell for DSELs. In a DSEL you might want string | literals to have a different type than the ordinary String. | | I have not implemented anything yet, but I would like to see | something along the lines of the following: | | class IsString s where | fromString :: String -> s | instance IsString String where | fromString = id | | The instance declaration is not allowed in Haskell-98, but it can be | rewritten as | class IsChar c where -- Make this class local to it's defining module | fromChar :: Char -> c | instance IsChar Char where | fromChar = id | instance (IsChar c) => IsString [c] where | fromString = map fromChar | | And, like with numeric literals, any string literal will then have an | implicit fromString insert to make the right conversion. | | My guess is that the defaulting mechanism needs to be extended to | default to the String type as well, or we'll get some ambiguous | expressions. | | Any thoughts? | | -- Lennart | | _______________________________________________ | Haskell-prime mailing list | Haskell-prime@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-prime
Lennart Augustsson wrote:
I think it's time that string literals got overloaded just like numeric literals.
I'm suspicious, but as long as a Char is never ever implicitly coverted to an integer type such as Word8, I suppose it might be OK. I will rant about this on request. -- Ashley Yakeley
There will never be any implicit conversion. Any overloading you create will have to decide how to treat the [Char]. -- Lennart On Nov 14, 2006, at 17:42 , Ashley Yakeley wrote:
Lennart Augustsson wrote:
I think it's time that string literals got overloaded just like numeric literals.
I'm suspicious, but as long as a Char is never ever implicitly coverted to an integer type such as Word8, I suppose it might be OK.
I will rant about this on request.
-- Ashley Yakeley
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
As long as no-one is tempted to create "instance IsChar Word8", I'll be happy. Have you considered possible type ambiguity issues? There may be a case for generalising "++" to the Monoid class, but that might not work well with this. -- Ashley Yakeley Lennart Augustsson wrote:
There will never be any implicit conversion. Any overloading you create will have to decide how to treat the [Char].
-- Lennart
On Nov 14, 2006, at 17:42 , Ashley Yakeley wrote:
Lennart Augustsson wrote:
I think it's time that string literals got overloaded just like numeric literals.
I'm suspicious, but as long as a Char is never ever implicitly coverted to an integer type such as Word8, I suppose it might be OK.
I will rant about this on request.
--Ashley Yakeley
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
I've certainly considered type ambiguity, but I don't know how bad it will be in practice. My small experiments indicate that things would work well. As for IsChar, the intention of that class is to have just one instance. The only reason for introducing it is to keep the instance declaration of IsString conforming to Haskell-98. -- Lennart On Nov 14, 2006, at 20:02 , Ashley Yakeley wrote:
As long as no-one is tempted to create "instance IsChar Word8", I'll be happy.
Have you considered possible type ambiguity issues? There may be a case for generalising "++" to the Monoid class, but that might not work well with this.
-- Ashley Yakeley
Lennart Augustsson wrote:
There will never be any implicit conversion. Any overloading you create will have to decide how to treat the [Char]. -- Lennart On Nov 14, 2006, at 17:42 , Ashley Yakeley wrote:
Lennart Augustsson wrote:
I think it's time that string literals got overloaded just like numeric literals.
I'm suspicious, but as long as a Char is never ever implicitly coverted to an integer type such as Word8, I suppose it might be OK.
I will rant about this on request.
--Ashley Yakeley
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
participants (8)
-
apfelmus＠quantentunnel.de -
Ashley Yakeley -
Bulat Ziganshin -
Dan Weston -
dons＠cse.unsw.edu.au -
John Meacham -
Lennart Augustsson -
Simon Peyton-Jones