Michael Snoyman wrote:
Heinrich Apfelmus wrote:
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.
Yes, indeed, it would be an alternative approach.
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
Good point. On the other hand, there is another extension, ViewPatterns,
which solves the problem of pattern matching on abstract data types in
full generality, allowing things like
handleList (viewAsStrings -> Element "ul" _ _) = ...
While more intrusive, the benefit of this extension is that a lot of
other code could likely become neater as well.
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.
Ah, I see. Since the Name type is abstract, I feel it's alright to add
the polymorphism to functions like element , but Map.lookup is indeed
a problem.
One option would be to make a new type NameMap specifically for Name
as key, but that seems a little overkill. The other option is to bite
the bullet and add the conversion by hand Map.lookup (name "class") .
In this case, I think I would go with a lightweight first option and
simply give a new name to the Map.lookup combination and use the
opportunity to sneak in some polymorphism.
getAttribute name = Map.lookup (toText name)
In my experience, turning all data types into abstractions works quite
well, but I can see that you can't avoid an annoying conversion if you
just want to use a quick Map.lookup .
Best regards,
Heinrich Apfelmus
--
http://apfelmus.nfshost.com
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
