Re: patch applied (haskell-prime-status): add overloaded string literals
Am Dienstag, 1. April 2008 00:31 schrieb Simon Marlow: Mon Mar 31 15:31:44 PDT 2008 Simon Marlow [EMAIL PROTECTED] * add overloaded string literals M ./status.hs +2 Hello, although I like overloaded string literals very much, I see one problem with the current implementation of them in GHC. It’s the class name “IsString”. No other Haskell class name I know starts with “Is”; we don’t have “IsNum”, “IsMonad”, etc. Would it be possible to change the class name “IsString” to something different? Would it be possible to remove the type alias “String” and let “String” be the class name? Can I add this remark somewhere on the wiki? Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: patch applied (haskell-prime-status): add overloaded string literals
Hello Wolfgang, Friday, April 11, 2008, 6:19:26 PM, you wrote: Would it be possible to change the class name “IsString” to something different? Would it be possible to remove the type alias “String” and let “String” be the class name? Can I add this remark somewhere on the wiki? this reminds me one idea i've once proposed to discuss: allow to use class names in type signatures with obvious translation to classic code: putStr :: String - IO () means putStr :: (String a) = a - IO () writing a lot of polymorphic code for Streams lib, i've found this feature very useful - with current standard, type signatures using type classes are very hard to read: -- | Copy `size` bytes from one BlockStream to another copyStream :: (BlockStream h1, BlockStream h2, Integral size) = h1 - h2 - size - IO () -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
patch applied (haskell-prime-status): add overloaded string literals
Mon Mar 31 15:31:44 PDT 2008 Simon Marlow [EMAIL PROTECTED] * add overloaded string literals M ./status.hs +2 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String literals
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
Re: String literals
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String literals
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: String literals
In my experience I've seen more requests for overloaded *Boolean* literals than strings. In a Fran context, for example. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: String literals
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, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String literals
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) ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
String literals
On Mon Nov 13 12:27:08 EST 2006, Simon Peyton-Jones wrote: In my experience I've seen more requests for overloaded *Boolean* literals than strings. In a Fran context, for example. Has there been discussion of the related issue, described in a Pan paper as 'Unfortunately, the Bool type is wired into the signatures of operations like = and ||.'? (I searched the trac but couldn't find it?) It seems common to have to write something like: class OrdE a where (*) :: a - a - a etc. While for finite signals both have meaning, ie. [1,2,3] [1,2,1] == True [1,2,3] * [1,2,1] == [False,False,True] for infinite signals '' is often a nonsense, and if these are the primary type it'd be nice to write '' for '*'. Regards, Rohan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String literals
While for finite signals both have meaning, ie. [1,2,3] [1,2,1] == True [1,2,3] * [1,2,1] == [False,False,True] Also, as the signature I gave implied, [1,2,3] * [1,2,1] == [0,0,1] And ifE etc., all as described in the paper I mentioned without referencing: 'Compiling Embedded Languages', Elliott, Finne and de Moor, 2000. I suspect this is well trodden ground, but I can't find the 'why is it so' writeup. Thanks, Rohan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String literals
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: [EMAIL PROTECTED] [mailto:haskell-prime- [EMAIL PROTECTED] 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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String literals
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, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: String literals
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,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
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
Re: String literals
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
