It seems that my previous mail went unnoticed. Perhaps because I didn't provide
enough
justification for my solution. I'll try to make up for that now.
First of all let's remind ourselves why orphan instances are a problem. Let's
say package A
defines some data types and package B defines
You're not the first one to come up with this idea (and I don't know who
is). Unfortunately, there are some complications. I'm pretty sure there are
simpler examples than this, but this is what I could think of. Suppose we
have
module PotatoModule (Root (..), T (..)) where -- Does not export
These are certainly good points and I'm far from claiming that I have solved
all the potential
problems that may arise (if I had I would probably be implementing this right
now). But I still
believe that pragmas are not a good solution, while control of imports and
exports is. Unless the
: Avoiding the hazards of orphan instances without
dependency problems
To: ghc-devs@haskell.org
Cc: RodLogic d...@rodlogic.net, David Feuer david.fe...@gmail.com
It seems that my previous mail went unnoticed. Perhaps because I
didn't provide enough
justification for my solution. I'll try to make up
As far as I can tell, all the ideas for really solving the problem are
either half-baked ideas, ideas requiring a complete re-conception of
Haskell (offering both ups and downs), or long term lines of research that
will probably get somewhere good some day, but not today. Yes, it would be
great to
Perhaps you misunderstood my proposal if you think it would prevent anyone
else from defining instances of those classes? Part of the proposal was
also adding support to the compiler to allow for a multiple files to use a
single module name. That may be a larger technical challenge, but I think
On Oct 21, 2014 1:22 PM, John Lato jwl...@gmail.com wrote:
Perhaps you misunderstood my proposal if you think it would prevent
anyone else from defining instances of those classes? Part of the proposal
was also adding support to the compiler to allow for a multiple files to
use a single module
One other benefit of multiple files to use a single module name is that it
would be easy to separate testing code from real code even when testing
internal/non-exported functions.
On Tue, Oct 21, 2014 at 1:22 PM, John Lato jwl...@gmail.com wrote:
Perhaps you misunderstood my proposal if you
In the past I've spent some time thinking about the orphan instances problem. I
concluded that the
Right Thing to do is to turn instances into first-class citizens and allow them
to be explicitly
imported and exported. I think devising pragmas is a workaround, not a solution.
Janek
Dnia
Orphan instances are bad. The standard approach to avoiding the orphan
hazard is to always put an instance declaration in the module that declares
the type or the one that declares the class. Unfortunately, this forces
packages like lens to have an ungodly number of dependencies. Yesterday, I
had
On Sun, Oct 19, 2014 at 1:02 PM, David Feuer david.fe...@gmail.com wrote:
with a flag -XAllowForbiddenInstancesAndInviteNasalDemons
One could argue this is spelled -XIncoherentInstances
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com
Although they have the same nasal-demon-inducing effects,
IncoherentInstances and AllowForbiddenInstances would turn off errors that
result from distinct situations. It's possible that one might want to play
with forbidden instances in development, keeping the standard coherence
checks in place,
Thinking about this, I came to a slightly different scheme. What if we
instead add a pragma:
{-# OrphanModule ClassName ModuleName #-}
and furthermore require that, if OrphanModule is specified, all instances
can *only* appear in the module where the class is defined, the involved
types are
I don't think your approach is flexible enough to accomplish the purpose.
For example, it does almost nothing to help lens. Even my approach should,
arguably, be extended transitively, allowing the named module to delegate
that authority, but such an extension could easily be put off till later.
I fail to see how this doesn't help lens, unless we're assuming no buy-in
from class declarations. Also, your approach would require c*n pragmas to
be declared, whereas mine only requires c. Also your method seems to
require having both the class and type in scope, in which case one could
simply
OK, so first off, I don't have anything against your pragma; I just think
that something akin to mine would be good to have too. Mine was not
intended to require both class and type to be in scope; if one of them is
not, then it should be given its full name:
{-# InstanceIn Module Foo.Class Type
16 matches
Mail list logo
