String literals

[apfelmus at quantentunnel.de]

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