A question about run-time errors when class members are undefined

[Anthony Clayden]

On Mon, 8 Oct 2018 at 8:41 PM, Simon Peyton Jones  wrote

You may be interested in Carlos Camarao’s interesting work.  For a long
> time now he has advocated (in effect) making each function into its own
> type class, rather that grouping them into classes.   Perhaps that is in
> line with your thinking.
>

Could I ask Simon direct, since it was he who introduced the topic. When
you say "interesting work", what is that evaluation based on? Is there a
paper or summary you've seen that expresses the ideas? (Because despite the
exhaustive and exhausting rounds on github last year, and further comment
on this thread, I just can't see anything workable. And the papers that
Carlos references ring alarm bells for me, just looking at the Abstracts,
let alone delving into the impenetrable type theory.)

And could I ask Carlos: are we allowed to know who peer-reviewed your
papers? Specifically, was it someone who's up with the state of the art in
GHC?

Carlos/his team are making bold claims: to provide the functionality of
FunDeps/Type functions, Overlapping Instances/Closed Type Families, to
avoid the infamous `read . show` ambiguity, to avoid the equally infamous
'orphan instances' incoherence, to preserve principal typing, and to keep
it "simple".

Then I have to say that if there's evidence for those claims, it's not
appearing in the papers. Really the only example presented is `read . show`
(plus record field disambiguation). Yes I'd hope the approach for a simple
example is "simple". It doesn't seem any more simple than putting an
explicit type signature (or we could use type application `@` these days).
But I don't expect that would be the place to show off the
power/expressivity.


Thank you
AntC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20181011/b19878d1/attachment.html>