>>>
>>> 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
