Actually, I just tried to make an example of this, and GHC does not seem to
export `f`, just as the report says. So I'd say GHC is behaving correctly,
both with the exports and the warning.
On Fri, May 12, 2017 at 10:39 AM, Iavor Diatchki <iavor.diatc...@gmail.com>
wrote:
&
Hello,
actually, the bug here is that `f` is exported, as omitting the export list
is not equivalent to writing `module A` in the export list.
This is explicitly stated in Section 5.2 of the Haskell report:
"If the export list is omitted, all values, types and classes defined in
the module are
Hello,
these two instances really should be rejected as they violate the FD of the
class: we can derive `TypeEq a a True` using the first instance and `TypeEq
a a False` using the second one. Unfortunately, the check that we are
using to validate FDs when `UndecidableInstances` is on, is not
Hi,
the initial plan was that `GHC.TypeLits` should provide just the basic
functionality, and later other libraries would be build to provide more
convenient functions for specific applications. I don't know of any such
convenience libraries, so at present, people just import `GHC.TypeLits`
Hello,
when you parse the CSV fully, you end up creating a lot of small bytestring
objects, and each of these adds some overhead. The vectors themselves add
up some additional overhead. All of this adds up when you have as many
fields as you do. An alternative would be to use a different
Hello Ben,
I posted this when you originally asked for feed-back, but perhaps it
got buried among the rest of the e-mails.
I think the proposal sounds fairly reasonable, but it is hard to say how
well it will work in practice until we try it, and we should be ready to
change it if needs be.
Hello Manuel,
this is exactly the change that is being discussed: currently a `case`
expression is not considered to be atomic (`aexp`), which is why it can't
appear in a record update without parens.
The proposed change, as I understand it, is to make `case` (and `do`) into
atomic expressions
Hello,
I think this sounds fairly reasonable, but it is hard to say how well it
will work in practice until we try it.
Some clarifying questions on the intended process:
1. After submitting the initial merge request, is the person making the
proposal to wait for any kind of acknowledgment,
Hello,
while we are voting here, I kind of like this proposal, so +1 for me.
I understand that some of the examples look strange to Haskell old-timers
but, as Joachim points out, the behavior is very consistent. Besides, the
"Less Obvious Examples" were selected so that they are, well, less
I think that biographical profiling is quite nice! I wouldn't say that it
is *more* useful than other modes of profiling, but it is certainly
complementary, and helps give you an idea of what's going on.
So I'd very much vote for fixing it rather than removing it.
-Iavor
On Fri, May 6, 2016 at
Hi,
that's an interesting example. To me this looks like a bug in GHC,
although the issue is certainly a bit subtle.
The reason I think it is a bug is that, if we name all the type functions
in the signature and apply improvements using the fact that we are working
with functions, then we get:
Hello,
actually type-level integers are easier to work with than type-level
naturals (e.g., one can cancel things by subtracting at will). I agree
that ideally we want to have both integers and naturals (probably as
separate kinds). I just don't know what notation to use to distinguish the
. Unfortunately I'm not sure we can easily unflatten *some*
constraints, given the way unflattening will work in the new
getInertUnsolved. One option might be for tcPluginSolve to be called in
both places, with a boolean parameter.
Cheers,
Adam
On 18/10/14 23:33, Iavor Diatchki wrote:
Hello
constraint; these are removed from the inert set, and re-added as
insoluable.
Happy hacking,
-Iavor
On Fri, Oct 17, 2014 at 3:36 PM, Iavor Diatchki iavor.diatc...@gmail.com
wrote:
Hello,
On Thu, Oct 16, 2014 at 3:58 AM, Adam Gundry a...@well-typed.com wrote:
One problem I've run
Hello,
On Thu, Oct 16, 2014 at 3:58 AM, Adam Gundry a...@well-typed.com wrote:
One problem I've run into is transforming the flattened CFunEqCans into
unflattened form (so the flatten-skolems don't get in the way of
AG-unification). Do you know if there is an easy way to do this, or do I
wrote:
yay :)
On Mon, Oct 6, 2014 at 2:42 PM, Iavor Diatchki iavor.diatc...@gmail.com
wrote:
Hi Adam,
I am back from vacation, and I think I should have some time to try to
implement something along these lines.
Cheers,
-Iavor
On Fri, Sep 12, 2014 at 9:41 AM, Adam Gundry a...@well
Hi Adam,
I am back from vacation, and I think I should have some time to try to
implement something along these lines.
Cheers,
-Iavor
On Fri, Sep 12, 2014 at 9:41 AM, Adam Gundry a...@well-typed.com wrote:
Hi folks,
Those of you at HIW last week might have been subjected to my lightning
Hello,
What semantics are you using for recursive modules? As far as I see, if
you take a least fixed point semantics (e.g. as described in A Formal
Specification for the Haskell 98 Module System,
http://yav.github.io/publications/modules98.pdf ) this program is incorrect
as the module does not
Hello,
this is clearly a bug in GHC: where `B` and `C` are imported, there should
have been an error, saying that there is a duplicate instance of `Foo Int`.
If there is no ticket for this already, could you please add one?
-Iavor
On Mon, Aug 11, 2014 at 12:35 PM, Dan Doel
Hello,
Such a pragma sounds useful, and is very much like the fails instance
from the Instance chains paper. You may also be interested in ticket
#9334 (https://ghc.haskell.org/trac/ghc/ticket/9334), which proposes an
alternative to overlapping instances, and I just updated it to point to
#7775.
Hello,
I have no strong feelings about what words we use, but I wanted to point
out that while we are thinking of names, we may want to consider 3 (and not
just 2). Currently we have:
* OVERLAPPING: This instances may overlap existing instances
* OVERLAPPABLE: This instance may be
Hi Henning,
I see two separate issues that show in what you describe, so it might be
useful to discuss them separately:
1. The first issue is figuring out that `n + 1` is always at least 1. As
others have mentioned, GHC currently only does proofs by evaluation,
which is why it gets stuck here.
Hello,
My preference would be for the following design:
1. The default datatypes for roles are Nominal, but programmers can add
annotations to relax this.
2. Generlized newtype deriving works as follows: we can coerce a
dictionary for `C R` into `C T`, as long as we can coerce the types of all
Hello,
I talked to Simon PJ about this at ICFP, and the use case that I'm
interested in is the one where we infer an `Applicative` constraint instead
of `Monad` for things of the form:
do { x1 - e1; x2 - e2; ...; pure (f x1 x2 ...) }
as long as the `xs` do not appear in the `es`. I am
Hello,
I think that the simple type nats solver (branch type-nats-simple) is
pretty much ready for merging with HEAD. Should I go ahead and merge it in?
-Iavor
On Thu, Sep 12, 2013 at 1:18 PM, Austin Seipp aus...@well-typed.com wrote:
I think this can definitely be clarified. I'll update
Hello Austin,
On Sun, Sep 8, 2013 at 4:27 PM, Austin Seipp ase...@pobox.com wrote:
* Iavor Diatchki and SPJ are working together on the type-nats-simple
branch. I believe this will hopefully land in time. Iavor, SPJ - can
you comment here?
I think we are on track to get this done on time
Hi,
This does not appear to be related to ImplicitParameters, rather
`MonoLocalBinds` is not working as expected.
Here is an example without implicit parameters that compiles just fine, but
would be rejected if `p` was monomorphic:
{-# LANGUAGE NoMonomorphismRestriction, MonoLocalBinds #-}
notation was
something like x := 2).
Perhaps we should revisit it, it seems much simpler than the rather
surprising behavior of `MonoLocalBinds`.
-Iavor
On Thu, Mar 28, 2013 at 4:39 PM, Iavor Diatchki iavor.diatc...@gmail.comwrote:
Hi,
This does not appear to be related to ImplicitParameters
Hello,
I think that there are a lot of useful features that are in HEAD that would
be useful to a wider audience than GHC devs, so a release before October
would certainly be useful. I don't think it is that important if it is
called 7.7.1 or 7.8.1 but I think that it needs to be a fixed
Hello,
I was just doing some work with Template Haskell and I noticed that the AST
does not have support for record puns and wild-cards. I know that these
could be desugared into ordinary record patterns but I think that it would
be more convenient for users (and also more consistent with the
Hello,
(sorry for the repost, I forgot to add a subject.)
I was just doing some work with Template Haskell and I noticed that the AST
does not have support for record puns and wild-cards. I know that these
could be desugared into ordinary record patterns but I think that it would
be more
Hello,
I think that it'd be really useful to be able to just declare a `kind`
without having to promote a datatype.
When we discussed this last time (summarized by the link Pedro sent, I
think) it came up that it might be nice to also
have kind synonyms, which would be analogous to type
Hello,
The general functionality for this seems useful, but we should be careful
exactly what types we allow in the 'newtype wrap/unwrap' declarations. For
example, would we allow something like this:
newtype wrap cvt :: f a - f (Dual a)
If we just worry about what's in scope, then it should
Hello Conal,
The issue with your example is that it is ambiguous, so GHC can't figure
out how to instantiate the use of `foo`. It might be easier to see why
this is if you write it in this form:
foo :: (F a ~ b) = b
foo = ...
Now, we can see that only `b` appears on the RHS of the `=`, so
Hello,
On Sun, Jan 13, 2013 at 12:05 PM, Conal Elliott co...@conal.net wrote:
so there is really no way for GHC to figure out what is the intended value
for `a`.
Indeed. Though I wonder: does the type-checker really need to find a
binding for `a` in this case, i.e., given the equation
Hello Conal,
GHC implementation of functional dependencies is incomplete: it will use
functional dependencies during type inference (i.e., to determine the
values of free type variables), but it will not use them in proofs, which
is what is needed in examples like the one you posted. The reason
Hello,
I also sometimes wish that GHC developer discussions happened in a single
place, separate from the commits and ticket lists (at present they are
sometimes on ghc-users and sometimes on cvs-ghc). For what it's worth, I
don't follow the commit and build-bot messages closely, instead I use
Hello,
While working on GHC sometimes I find it useful to dump the values of
intermediate expressions, perhaps in the middle of pure code, using a
combination of `trace` and `ppr`. The issue is that `ppr` returns an
`SDoc`, and to turn an `SDoc` into a `String`, I need some `DynFlags`.
There
that.
·Iavor mutters about sketchiness, but I’m not sure what that
means specifically.
·I’m not sure how, it at all, it affects Richard’s singletons
paper
Simon
*From:* Iavor Diatchki [mailto:diatc...@galois.com]
*Sent:* 12 October 2012 21:11
*To:* Richard Eisenberg
? Ian said
that it is somewhere in the nightly build logs but I don't where to look.
-Iavor
On Thu, Sep 20, 2012 at 7:20 AM, Simon Marlow marlo...@gmail.com wrote:
On 19/09/2012 02:15, Iavor Diatchki wrote:
exactly what git's submodule machinery does, so it seems pointless
Hello,
On Tue, Sep 18, 2012 at 12:10 AM, Simon Peyton-Jones
simo...@microsoft.comwrote:
The technically-straightforward thing to do is to add kind application,
but that's a bit complicated notationally.
http://hackage.haskell.org/trac/ghc/wiki/ExplicitTypeApplication Does
anyone have any
Hello,
I was just trying to build the GHC-7.6 branch from source and the build
failed with type-errors, because the libraries used by GHC have moved on
since the release, and sync all just gets the most recent version.
Is there a fingerprint somewhere so that I can checkout the libraries in
a
Hello,
On Tue, Sep 18, 2012 at 1:25 PM, Ian Lynagh i...@well-typed.com wrote:
Why do you want to build 7.6 but not 7.6.1, OOI?
I was trying to build a different branch which is a fork of 7.6---I
wanted to play around with the profiling suite described in the Core
Diving talk from the Haskell
Hello,
I think that it would be a mistake to have two pragmas with incompatible
behaviors: for example, we would not be able to write modules that use
Conal's libraries and, say, the type nats I've been working on.
If the main issue is the notation for arrows, has anoyone played with what
can be
Hello,
the functions on type literals on the master branch are not yet
implemented. If you want to play around with these kinds of things,
please use the type-nats branch (please note that this is a development
branch so things may occasionally break!).
In the first example, GHC is saying that
Hello,
I am late to the discussion and this is not entirely on topic, for which I
apologize, but I like the multi-branch case syntax someone mentioned
earlier:
Writing:
case
| p1 - e1
| p2 - e2
| ...
desugars to:
case () of
_ | p1 - e2
| p2 - e2
| ...
-Iavor
PS: I
Hi Paolo,
I agree that this would be useful. In fact, a couple of years ago I
implemented this in GHC, but after some discussion folks were not convinced
that it's a good idea. I don't remember the details but as far as I recall
we agreed to disagree :-) The e-mail thread is over here:
Hello,
On Mon, Feb 20, 2012 at 7:03 PM, Johan Tibell johan.tib...@gmail.comwrote:
Looks really nice.
Thanks!
The hovering behavior is nice, but I'd like to see
the legend as well. It makes it quicker when you want to get a quick
overview of what types there are, as the eye can travel
Hello,
On Mon, Feb 13, 2012 at 5:32 PM, Edward Kmett ekm...@gmail.com wrote:
There are fewer combinators from commonly used classes for working with
the left argument of a bifunctor, however.
I think that the bifunctor part of Bas's version is a bit of a red herring.
What I like about it is
Hello,
I like Bas's variation on the design (except, perhaps, for the name
Tagged ;) It captures exactly what we are trying to do: the
dictionary for Typeable becomes simply the run-time representation of
the type. Coincidentally, this is exactly the same as what I am using
to link value level
Hello,
On Wed, Jan 25, 2012 at 7:21 AM, Thijs Alkemade thijsalkem...@gmail.com wrote:
Also, we have a confusing problem when type checking a module. Above,
we showed the result of :t map __ __ in ghci. However, if we put f
= map __ __ in a module, we get:
tcRnModule: [(f.hs:1:9-10,
Hello,
My preference would be to change the behavior of the TypeOperator
flag. Here is my reasoning:
* Having two operators with slightly different meanings would be
very confusing, not just for beginners but for everyone.
* The two behaviors are not compatible in the sense that they can't
Hello,
On Mon, Jan 2, 2012 at 4:38 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
· I don’t know exactly what you have in mean by “the ability to
reflect the type-level string at the value level”.
This can be done using singleton types in exactly the same way that it
is done on
Hello,
Does anyone have any advice about how I might make a smallish GHC installation?
The context is that I need to make a demo VM, which has a limited
amount of space, and I'd like to have GHC installed on the system but
the default GHC installation (~700MB) does not fit. The installation
/
As it's very very fast and has a pleasant UI, but I'm not partial
either way (gitweb is probably more than robust enough to handle a
repo of GHC's size I'm sure.)
On Tue, Jun 21, 2011 at 12:09 PM, Iavor Diatchki
iavor.diatc...@gmail.com wrote:
Hello,
Do we have an instance of gitweb
Hello,
Do we have an instance of gitweb for the various ghc related repos running
somewhere? If not, I'd be happy to setup an instance, would anyone object?
gitweb is a web-interface which makes it easy to get a quick overview of
what's going on with a collection of repositories. It shows
Hello,
shouldn't the check go the other way? (i.e., if the RHSs unify, then the
LHS must be the same). Here is an example:
-- This function is not injective.
type instance F a = Int
type instance F b = Int
Still, Conal's example would not work if we just added support for injective
type
Hello,
thanks for this Simon! I've ported my work on the type-naturals feature as
a git branch, and everything seems to be working as expected so far. I've
put my modified repos at http://code.galois.com/cgi-bin/gitweb (their names
all start with the type-naturals prefix). I am sending the link
, Simon Marlow marlo...@gmail.com wrote:
On 12/01/2011 22:22, Iavor Diatchki wrote:
Hello,
On Wed, Jan 12, 2011 at 11:44 AM, Roman Leshchinskiy r...@cse.unsw.edu.au
mailto:r...@cse.unsw.edu.au wrote:
On 12/01/2011, at 09:22, Simon Marlow wrote:
On 11/01/2011 23:11, Roman Leshchinskiy
Hello,
On Wed, Jan 12, 2011 at 11:44 AM, Roman Leshchinskiy
r...@cse.unsw.edu.auwrote:
On 12/01/2011, at 09:22, Simon Marlow wrote:
On 11/01/2011 23:11, Roman Leshchinskiy wrote:
A quick look at the docs seems to indicate that we'd need to do
git pull
git submodule update
Hello,
On Mon, Jan 10, 2011 at 12:49 PM, Roman Leshchinskiy
r...@cse.unsw.edu.auwrote:
On 10/01/2011, at 13:27, Simon Marlow wrote:
It would be a prerequisite to switching that a GHC developer only has to
use one VCS. So we either migrate dependencies to git, or mirror them in
Hello,
I have been working on a GHC branch for the last few months and, for me,
switching to git would be a win because I find it quite difficult to keep my
branch and HEAD synchronized. I allocate about a day, probably about once a
month, to redo my repository so that it is in sync with HEAD.
Hello,
Another design-pattern which sometimes works pretty well is to
encapsulate commonly used polymorphic types in ordinary data-types
(i.e., use the rank-2 style). Then, the data-type constructors provide
a quick way to---essentially---write a type signature. It seems that
this should work well
Hello,
Thanks for all your responses (and the --skip-conflicts tip)! I use
git for a lot of my development, so I was hoping that I was just
experiencing culture shock and simply doing things with the wrong
mind-set. Given the responses though, it sounds like this is a well
known problem with
Hello,
I am doing some work on a GHC branch and I am having a lot of troubles
(and spending a lot of time) trying to keep my branch up to date with HEAD,
so I would be very grateful for any suggestions by fellow developers of how
I might improve the process. Here is what I have tried so far:
memory at run time. I've had
fairly serious difficulties when trying to explain why this happens to
programmers who are not Haskell implementors.
On Wed, Mar 17, 2010 at 8:21 AM, Tyson Whitehead twhiteh...@gmail.com wrote:
On March 16, 2010 20:01:32 Iavor Diatchki wrote:
Optionally disabling
.
-Iavor
On Mon, Mar 15, 2010 at 5:57 PM, Ian Lynagh ig...@earth.li wrote:
On Mon, Mar 15, 2010 at 09:48:02AM -0700, Iavor Diatchki wrote:
I have a darcs patch implementing the feature but I could not send it
to the list because for some reason the patch is 150K long (!!! my
changes are only
without the need for adjustor thunks.
-Iavor
On Tue, Mar 16, 2010 at 4:47 PM, Isaac Dupree
m...@isaac.cedarswampstudios.org wrote:
On 03/16/10 19:38, Iavor Diatchki wrote:
The fact that, at present, all GHC-compiled programs require an
executable data segment is a fairly significant problem
Hello,
I have implemented a small extension to the FFI which allows for
static_wrapper imports. These are a variation on wrapper imports
that do not use run-time code generation. This is important in
security sensitive contexts because it avoids executable data. While
static_wrapper imports are
and potential errors.
-Iavor
On Mon, Mar 15, 2010 at 3:56 PM, Tyson Whitehead twhiteh...@gmail.com wrote:
On March 15, 2010 12:48:02 Iavor Diatchki wrote:
I have implemented a small extension to the FFI which allows for
static_wrapper imports. These are a variation on wrapper imports
that do
, KindSignatures #-}
module GADT where
data Foo :: * - * where
Foo :: Int - Foo Int
Iavor Diatchki wrote:
Hello,
Sorry for responding so late---I just saw the thread. I don't think
that we should deprecate the usual way to define existentials. While
the GADT syntax is nice in some cases
Hi,
Perhaps it would make sense to add something along those lines to the
documentation for Foreign.newForeignPtr as well?
-Iavor
On Mon, Apr 27, 2009 at 5:32 AM, Simon Marlow marlo...@gmail.com wrote:
On 27/04/2009 01:28, Sigbjorn Finne wrote:
On 4/25/2009 07:16, Ian Lynagh wrote:
On Fri,
Hi,
Thanks for the feedback! Suggestions implemented in your daily
value-supply release :)
Happy Holidays!
-Iavor
On Wed, Dec 24, 2008 at 7:46 AM, Isaac Dupree isaacdup...@charter.net wrote:
Iavor Diatchki wrote:
Also, your
implementation of it could be more efficient: it doesn't need to do
in practise.
If anyone has further ideas, please chime in.
-Iavor
On Tue, Dec 23, 2008 at 8:30 AM, Isaac Dupree isaacdup...@charter.net wrote:
Iavor Diatchki wrote:
- It uses unsafeDupableInterleaveIO to avoid double locking,
in particular,
gen r = unsafeDupableInterleaveIO
$ do v
Hello,
Thanks for your comments!
On Tue, Dec 23, 2008 at 3:22 PM, Isaac Dupree isaacdup...@charter.net wrote:
unsafeInterleaveIO is cheap until you need to evaluate its result. So how
about this, I think it makes there be 1/3 as many structural
unsafeInterleaveIO's, so if it took 2 amount
Hi,
Thanks for the feedback! I have uploaded a new version of value
supply with the following changes that should improve performance.
- It uses unsafeDupableInterleaveIO to avoid double locking,
- Do not create an intermediate list for Enum and Num supples
- Specialize code for Int, as
Hello,
I have made the two changes that Simon suggested and uploaded a new
version of the library. By the way, GHC seemed to work correctly
even without the extra boolean parameter, perhaps it treats
unsafePerformIO specially somehow? A somewhat related question: I
ended up using three calls
Hi,
On Thu, Aug 28, 2008 at 6:59 AM, Simon Marlow [EMAIL PROTECTED] wrote:
Because if you *can* use Cabal, you get a lot of value-adds for free (distro
packages, cabal-install, Haddock, source distributions, Hackage). What's
more, it's really cheap to use Cabal: a .cabal file is typically less
Hello,
On Tue, Aug 12, 2008 at 5:49 PM, Manuel M T Chakravarty
[EMAIL PROTECTED] wrote:
Ian, I completely agree with you. I love the darcs vcs model, too.
However, we have three discussions here:
(1) Do we want darcs vcs model?
Except Thomas Schilling, who seems to be dead set to get
Hello,
I think that we should switch the repositories of the core libraries
to git too, not just because GHC is switching, but simply because git
is a more reliable RCS. It seems that this does not prevent other
implementations from using them---the code in the repositories will be
still the
Hi,
I also agree with Duncan---basic library functions should provide a
mechanism and not try to enforce a policy. Applications that are
interested in supporting the %HOME% convention can easily do so by
defining a function that first checks for that environment variable,
and only if it is not
Hi,
Just curious, what external modules does the Prelude depend on?
The only unusual feature that I can think of in the GHC Prelude is the
fact that the partial functions throw exceptions, and so perhaps the
Prelude implementation uses some extra modules for that?
-Iavor
On 6/6/07, Simon Marlow
Hello,
I am using GHC 6.6 and I am trying to build a library using Cabal.
The library is written in Haskell'98 so I made the Cabal file depend
only on the package haskell98. Unfortunately building the library
fails with the following error:
MyModule.hs:1:0:
Failed to load interface for
Hello,
I agree with Simon on this one: x-1 should parse as expected (i.e.,
the infix operator - applied to two arguments x and 1). Having
this result in a type error would be confusing to both beginners and
working Haskell programmers.
I think that if we want to change anything at all, we
Hello,
The same oddity with type checking can happen in Haskell 98 as well:
http://www.mail-archive.com/haskell@haskell.org/msg06754.html
-Iavor
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
Hello,
I think the it may be confusing to novices argument tends to be
over-used and we should be careful before we make language decisions
solely based on it. At the very least, when there is a suggestion
that something might be confusing to someone, there should be an
explanation of
Hello,
I have been using the .ghci file with GHCi to set global options for
my project and I find it very useful. The kind of options I put there
are: where to put .hi/.o files, what warnings to produce, where to
look for code. etc. It works great. I was thinking that it would be
very
Hello,
It appears that the instructions on the GHC 6.4.1 page for downloading
and installing debian packages are incorrect (see bellow).
-Iavor
On Wed, Sep 21, 2005 at 11:00:39AM -0700, Iavor Diatchki wrote:
Hello,
The GHC 6.4.1 download page
(http://haskell.org/ghc/download_ghc_641.html
Hello,
I am not sure what GHC is doing, it certainly seems to be
inconsistent. In Hugs both the examples work. In case you are
interested, here is how you can get a version that works in
both Hugs and GHC (I just modified your code a little):
{-# OPTIONS -fglasgow-exts
Hi,
I am surprised that GHC performs these checks when started with glasgow-exts.
Your example works with Hugs, but your are probably aware of this.
Just to support your case, I have also run into this problem,
but I still use hugs for prototyping so I didn't even notice that GHC
is so strict.
Hi,
On Apr 3, 2005 7:33 AM, Manuel M T Chakravarty [EMAIL PROTECTED] wrote:
Assume the following type class declarations with functional
dependencies:
{-# OPTIONS -fglasgow-exts #-}
class C a b c | a b - c where
foo :: (a, b) - c
instance C a a r = C a (b, c) r where
foo (a,
91 matches
Mail list logo
