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
wrote:
> Hello,
>
> actually, the bug h
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 quit
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`
dire
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
repr
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.
Some
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, or
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 ob
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 2
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
two.
great if the plugin could choose which it
> sees. 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.
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
wrote:
> Hello,
>
> On Thu, Oct 16, 2014 at 3:58 AM, Adam Gundry wrote:
>
>>
>>
>> One problem I've run
Hello,
On Thu, Oct 16, 2014 at 3:58 AM, Adam Gundry 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
> need to rebuild
...@gmail.com> wrote:
> yay :)
>
> On Mon, Oct 6, 2014 at 2:42 PM, Iavor Diatchki
> 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,
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 wrote:
> Hi folks,
>
> Those of you at HIW last week might have been subjected to my lightning
> talk on plugins fo
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 wrote:
> On M
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
#77
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 overlappe
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
m
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 intere
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 wrote:
> I think this can definitely be clarified. I'll update the docs a
> little lat
Hello Austin,
On Sun, Sep 8, 2013 at 4:27 PM, Austin Seipp 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
Hello,
On Fri, May 24, 2013 at 12:42 AM, Daniel Gorín wrote:
> On May 24, 2013, at 9:28 AM, Simon Peyton-Jones wrote:
>
> > How about (in Haskell98)
> >
> > module Data.List ( foldr, ...)
> > import qualified Data.Foldable
> > foldr :: (a -> b -> b) -> b -> [a] -> b
> >
e proposed 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 wrote:
> Hi,
> This does not appear to be related to
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 #-}
class
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 version,
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 convenie
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 res
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 synonyms,
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 b
Hello,
On Sun, Jan 13, 2013 at 12:05 PM, Conal Elliott 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 `(forall
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 `=>`, s
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 s
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
v
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 use
t back into a type family, which is a Good Thing because it paves the
> way for an eta rule. RSVP and I’ll do 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
>
? 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 wrote:
> On 19/09/2012 02:15, Iavor Diatchki wrote:
>
>> exactly what git's submodule machinery does, so it seems pointless to
Hello,
On Tue, Sep 18, 2012 at 1:25 PM, Ian Lynagh 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 Implementors
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 12:10 AM, Simon Peyton-Jones
wrote:
>
> 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 other ideas?
>
>
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
main2 :: String
main2 = case integerToInt main3 of
wild_ap2 { __DEFAULT -> $wshowSignedInt 0 wild_ap2 ([] @
Char) }
Note that, for some reason, the call to `integerToInt` is not eliminated.
I am not quite sure why that is.
-Iavor
> **
>
> Can you g
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
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:
http
Hello,
On Mon, Feb 20, 2012 at 7:03 PM, Johan Tibell wrote:
>
> 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 back-and-forth
> betw
Hello,
On Mon, Feb 13, 2012 at 5:32 PM, Edward Kmett 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 that it over
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 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, GHC.Prim.Any * -> b),
>
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
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 the type-nats branc
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
does
t;
> 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
> wrote:
> > Hello,
> >
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 functio
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 lin
rtable with the
rest of git's model.
-Iavor
On Thu, Jan 13, 2011 at 12:49 AM, Simon Marlow wrote:
> On 12/01/2011 22:22, Iavor Diatchki wrote:
>
>> Hello,
>>
>> On Wed, Jan 12, 2011 at 11:44 AM, Roman Leshchinskiy > <mailto:r...@cse.unsw.edu.au>> wrote:
Hello,
On Wed, Jan 12, 2011 at 11:44 AM, Roman Leshchinskiy
wrote:
> 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
wrote:
> 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
> GHC-specific git branches.
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.
M
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 d
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:
Fir
to a Haskell app
requires you to allow making executable 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 wrote:
> On March 16, 2010 20:01:32 Iavor Di
callbacks in
many C libraries without the need for adjustor thunks.
-Iavor
On Tue, Mar 16, 2010 at 4:47 PM, Isaac Dupree
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 sig
as an extension in its own right it would
> need its own flag, documentation etc.
>
> Cheers,
> Simon
>
>> -Iavor
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Mar 15, 2010 at 3:56 PM, Tyson Whitehead
>> wrote:
>>
now how to proceed.
-Iavor
On Mon, Mar 15, 2010 at 5:57 PM, Ian Lynagh 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 lo
cause
it avoids duplication, thus reducing clutter and potential errors.
-Iavor
On Mon, Mar 15, 2010 at 3:56 PM, Tyson Whitehead wrote:
> On March 15, 2010 12:48:02 Iavor Diatchki wrote:
>> I have implemented a small extension to the FFI which allows for
>> "static_wrappe
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" import
dule 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
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, there are also examples when it
is quite verbose. For example, there is a lot of repetition in
datatypes that hav
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 wrote:
> On 27/04/2009 01:28, Sigbjorn Finne wrote:
>>
>> On 4/25/2009 07:16, Ian Lynagh wrote:
>>>
>>> On Fri, Apr 24,
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 wrote:
> Iavor Diatchki wrote:
>>>
>>> Also, your
>>> implementation of it could be more efficient: it
Hello,
Thanks for your comments!
On Tue, Dec 23, 2008 at 3:22 PM, Isaac Dupree 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 of time on
> unsaf
matters in practise.
If anyone has further ideas, please chime in.
-Iavor
On Tue, Dec 23, 2008 at 8:30 AM, Isaac Dupree wrote:
> Iavor Diatchki wrote:
>>
>> - It uses unsafeDupableInterleaveIO to avoid double locking,
>
> in particular,
>
>> gen r = unsafeDu
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 this
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 to
Hello,
On Thu, Sep 4, 2008 at 1:30 PM, Duncan Coutts
<[EMAIL PROTECTED]> wrote:
>> cabal-install: it does not work well with packages that have flags
>> because it does not know what flags to use when building dependencies.
>> Really, packages with conditionals are different packages in one
>> ca
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
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 t
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 same!
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 s
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 `Pr
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, w
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
http://www.haskell.org/mailman/listi
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 what/why
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 convenient
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_
Hello,
I would like to install the following tools on a Debian Linux
distribution (testing flavor):
GHC 6.4, alex, happy, darcs
(I use Hugs from CVS, so I don't want to install the Debian version)
I would also like to be able to update/remove any one of these tools
independently (I know enough abou
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 -fallow-undecidable-instan
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.
T
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
97 matches
Mail list logo
