On 2/24/12 5:40 PM, Johan Tibell wrote:
I share Greg's concerns about polymorphic projections. For example,
given a function
sort :: Ord a => ...
we don't allow any 'a' that happens to export a operator that's
spelled<= to be passed to 'sort'. We have the user explicitly create
an instance and thereby defining that their<= is e.g. a strict weak
ordering and thus make sense when used with 'sort'. This explicitness
is useful, it communicates the contract of the function to the reader
and lets us catch mistakes in a way that automatically polymorphic
projections don't.
Automatically polymorphic projections feels like Go's structural
polymorphism, C++'s templates or C's automatic numeric coercions, and
I'm worried it'll lead to problems when used at scale. They're not
required to solve the problem we're trying to solve, so lets hurry
slowly and don't bake them in together with the namespacing problem.
At the very least use two different LANGUAGE pragmas so users can have
one without the other.
+1.
I'm not sure that I like the current proposals for how to control the
non/automatic-ness of polymorphism (for reasons I can spell out later,
if desired). But we definitely want to have something that's a bit more
cultured than simply making all record projectors polymorphic over records.
--
Live well,
~wren
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
