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
Re: String literals
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
Re: String literals
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⑈ ___ 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: [Haskell-cafe] Re: Fractional/negative fixity?
On Fri, 10 Nov 2006, Ben Rudiak-Gould wrote: > I'm surprised that no one has mentioned showsPrec and readsPrec. Anything more > complicated than negative fixities would require their interfaces to be > changed. Very true. Does it mean, that the Functional Graph Library has to become part of the Prelude? ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Fractional/negative fixity?
I'm surprised that no one has mentioned showsPrec and readsPrec. Anything more complicated than negative fixities would require their interfaces to be changed. -- Ben ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Fractional/negative fixity?
[EMAIL PROTECTED] wrote: I think that computable real fixity levels are useful, too. Only finitely many operators can be declared in a given Haskell program. Thus the strongest property you need in your set of precedence levels is that given arbitrary finite sets of precedences A and B, with no precedence in A being higher than any precedence in B, there should exist a precedence higher than any in A and lower than any in B. The rationals already satisfy this property, so there's no need for anything bigger (in the sense of being a superset). The rationals/reals with terminating decimal expansions also satisfy this property. The integers don't, of course. Thus there's a benefit to extending Haskell with fractional fixities, but no additional benefit to using any larger totally ordered set. -- Ben ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
