On Tue, Sep 25, 2012 at 6:21 PM, Heinrich Apfelmus
Michael Snoyman wrote:
Note that I wasn't necessarily advocating such a pragma. And a lot of my XML code actually *does* use two IsString instances at the same time, e.g.:
Element ("img" :: Name) (singleton ("href" :: Name) ("foo.png" :: Text)) [NodeComment ("No content inside an image" :: Text)]
In this particular case, would it make sense to use smart constructors instead?
The idea is that you can put the polymorphism in two places: either make the "output" polymorphic, or make the "input" polymorphic. The latter would correspond to a type
element :: (IsString name, IsString s, IsMap map) => name -> map name s -> [Element] element name map = Element (toName name) (toMap map)
One benefit would be that the function will accept any list as a map, not just list literals.
Just to clarify: this would be a *replacement* for OverloadedStrings usage, right? If used in conjunction with OverloadedStrings, we'd run into the too-much-polymorphism issue you describe in your initial email in this thread, since `element "foo'` would become `element (fromString "foo")` which would become `Element ((toName . fromString) "foo")`, and `toName . fromString` makes it ambiguous what the intermediate data type is. Assuming this is meant are a replacement, I see two downsides. Firstly, this would work for construction, but not for deconstruction. Currently, I can do something like: handleList :: Element -> Element handleList (Element "ul" _ _) = ... handleList e = e The other is that we've only solved one specific case by providing a replacement function. In order to keep code just as terse as it is now, we'd have to provide a whole slew of replacement functions. For example, consider the code: handleList (Element "ul" attrs _) = case Map.lookup "class" attrs of .... If we get rid of OverloadedStrings, then we need to either provide a replacement `lookup` function which performs the conversion from String to Name, or change all lookup calls to explicitly perform that lookup. Michael