Can anyone help Burak?
Simon
-Original Message-
From: burak ekici [mailto:ekcbu...@hotmail.com]
Sent: 24 January 2012 08:12
To: Simon Peyton-Jones
Subject: A Garbage Collection Question
Dear Dr. Jones,
this time I am disturbing you to ask a question about how
garbage collection is
Dear GHC users
As part of beefing up the kind system, we plan to implement the "Type
operators" proposal for Haskell Prime
http://hackage.haskell.org/trac/haskell-prime/wiki/InfixTypeConstructors
GHC has had type operators for some kind, so you can say
data a :+: b = Left a | Right b
but
| > Has *is* a type class. It can be used and abused like any other.
| > Record members with the same key ought to have the same semantics; the
| > programmer must ensure this, not just call them all "x" or the like.
| >
| > Weak types these are not. The selector type is well-defined. The value
| >
That's odd. Please do create ticket, thank you!
From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Reiner Pope
Sent: 18 January 2012 04:44
To: glasgow-haskell-users@haskell.org
Subject: PolyKinds: couldn't match kind `BOX' against `*'
Yitz: very helpful. Can you turn your proposal into a Wiki page? It's
different to Johan's.
Could you add examples? I don't fully understand your design.
| [This has the additional advantage of giving SPJ
| motivation to remain engaged, because he seems
| to prefer B. :)]
True: but that's b
| /tmp/Test.hs:4:1:
| The multi-parameter class `C' cannot have generic methods
| In the class declaration for `C'
Aha. Trawling the commit logs, this test is simply a vestige of the PREVIOUS
generic-class story, now long gone. So we can lift the restriction easily.
I'll commit a
ld be that it's quite a lot of work to specify and implement; but
still might not do the job in the eyes of our users.
Simon
| -Original Message-
| From: Johan Tibell [mailto:johan.tib...@gmail.com]
| Sent: 14 January 2012 18:39
| To: Simon Peyton-Jones
| Cc: Greg Weber; ingo.wechs
| > But note what has happened: we have simply re-invented SORF. So the
| > conclusion is this:
| >
| > the only sensible way to implement FDR is using SORF.
|
| An obvious question at this point: can records have unboxed fields?
| I'm worried a bit about the kinds that can appear in a has cons
Thanks to Greg for leading the records debate. I apologise that I
don't have enough bandwidth to make more than an occasional
contribution. Greg's new wiki page, and the discussion so far has
clarified my thinking, and this message tries to express that new
clarity. I put a conclusion at the end
tom line: I think we have agreed that what GHC implements is all we can
reasonably do for now. Yell if you disagree
Simon
| -Original Message-
| From: Gábor Lehel [mailto:illiss...@gmail.com]
| Sent: 09 January 2012 16:45
| To: Simon Peyton-Jones
| Cc: Andres Löh; Antoine Latter; glasgow-
Three things about this ConstraintKinds thread:
First, about
class Functor f where
type C f a :: Constraint
type C f a = ()
vs
class Functor f where
type C f :: * -> Constraint
type C f = \_ -> ()
I don't know any way of dealing in a decent way with the latter, because it
la
If you think there's a bug here, could you open a ticket a repro case, please?
Many thanks
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of Bogdan Opanchuk
| Sent: 09 January 2012 13:00
| To: C
| In regard to Labels versus Atom, etc., in my use case of converting
| between similar datatypes, it would be very reasonable to eventually
| add/remove prefixes/suffixes from these type-level reifications of
| constructor names. If type-level strings are not implemented as lists
| of characters,
unqualified?
Without a design it's hard to debate the pros and cons of different approaches
to the record question. If anyone is seriously advocating nested modules, the
first step is to work out a concrete design, in detail.
Simon
From: Gershom Bazerman [mailto:gersh...@gmail.com]
Sent:
l string at the value level".
Simon
From: Gershom Bazerman [mailto:gersh...@gmail.com]
Sent: 31 December 2011 19:12
To: Simon Peyton-Jones
Cc: Greg Weber; glasgow-haskell-users@haskell.org
Subject: Re: Records in Haskell
On Dec 31, 2011, at 1:28 PM, Simon Peyton-Jones wrote:
The trouble is tha
ion to hold up
a records implementation now, just possibly modify things slightly.
Greg Weber
On Thu, Dec 29, 2011 at 2:00 PM, Simon Peyton-Jones
mailto:simo...@microsoft.com>> wrote:
| The lack of response, I believe, is just a lack of anyone who
| can cut through all the noise and come up with
| The lack of response, I believe, is just a lack of anyone who
| can cut through all the noise and come up with some
| practical way to move forward in one of the many possible
| directions.
You're right. But it is very telling that the vast majority of responses on
http://www.reddit.c
: GHC 7.4.1 Release Candidate 1
Hi Wolfgang,
On Wed, Dec 28, 2011 at 13:51, Wolfgang Jeltsch
mailto:g9ks1...@acme.softbase.org>> wrote:
Am Mittwoch, den 28.12.2011, 12:48 +0000 schrieb Simon Peyton-Jones:
> | By the way, is there a reason behind the fact that "Constraint" uses the
| By the way, is there a reason behind the fact that “Constraint” uses the
| ordinary case, while “BOX” has all three letters capitalized? Wouldn’t
| it be more sensible if it were “Box” instead of “BOX”?
Only that BOX is a sort (currently the one and only sort), whereas Constraint
is a kind. I'
| > Just of out curiosity, what would be a compelling use case for singleton
| and unit unboxed tuples?
|
| For singleton unboxed tuples, any situation where you want to return a
| single value but not force its evaluation. This occurs for example
| with some low level functions in the implementat
design and implementation?
Volunteers, stand forth!
Simon
From: Greg Weber [mailto:g...@gregweber.info]
Sent: 09 December 2011 19:38
To: Simon Peyton-Jones
Cc: Wolfgang Jeltsch; glasgow-haskell-users@haskell.org
Subject: Re: Records in Haskell
Are Records stalled out again? I am perfectly
011 16:41
To: Simon Peyton-Jones
Cc: Bas van Dijk; glasgow-haskell-users@haskell.org
Subject: Re: ConstraintKinds and default associated empty constraints
On Fri, Dec 23, 2011 at 10:17 AM, Simon Peyton-Jones
mailto:simo...@microsoft.com>> wrote:
Right now it seems it is either * or Constrai
:37
| To: glasgow-haskell-users@haskell.org
| Subject: Re: Unit unboxed tuples
|
| On 23/12/2011 13:46, Ian Lynagh wrote:
| > On Fri, Dec 23, 2011 at 01:34:49PM +0000, Simon Peyton-Jones wrote:
| >>
| >> Arguments Boxed Unboxed
| >> 3 ( , ,
figure out which is intended from context.
S
From: Edward Kmett [mailto:ekm...@gmail.com]
Sent: 23 December 2011 15:05
To: Simon Peyton-Jones
Cc: Bas van Dijk; glasgow-haskell-users@haskell.org
Subject: Re: ConstraintKinds and default associated empty constraints
Fair enough.
So if I understand y
| So the 'where' binding in the following does not get generalized
| because it could not have been written at the top level, correct?
The other way round. 'where' bindings that could have been written at top
level *are* generalised; ones that could not are *not* generalised. See "Which
bindin
:38PM +0000, Simon Peyton-Jones wrote:
| > Dear GHC users
| >
| > I've just discovered something very peculiar with unboxed tuples in GHC.
|
| The problem is that there is no boxed singleton tuple, whereas there is
| an unboxed singleton tuple, so there is a conflict between the data
| co
Dear GHC users
I've just discovered something very peculiar with unboxed tuples in GHC.
f2 x = (# True, False #)
f1 x = (# True #)
f0 x = (# #)
What types do these functions have?
f2 :: a -> (# Bool, Bool #)
f1 :: a
it’s a bug. I’m fixing it.
Simon
From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Edward Kmett
Sent: 22 December 2011 17:03
To: Bas van Dijk
Cc: glasgow-haskell-users@haskell.org
Subject: Re: ConstraintKinds and default associated e
Yes, it's expected; it's also the behaviour of GHC 6.12 etc.
Here what is happening. You define
result = undefined
What type does it get? In 6.12, and 7.4, it gets type
result :: forall b. b
So the two uses of 'result' in the two branches of the case have no effect on
each other
| 2011/12/22 Edward Kmett :
| > The change, however, was a deliberate _break_ with the standard that
| > passed through the library review process a few months ago, and is now
| > making its way out into the wild.
|
| Is it reasonable to enquire how many standard-compliant implementations
|
What about
class Functor f where
type C f :: * -> Constraint
type C f = ()
After all, just as (Ord a, Show a) is a contraint, so is ().
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf O
| Am Montag, den 12.12.2011, 15:37 -0500 schrieb wren ng thornton:
| > I've noticed that take and filter are good producers (and consumers)
| > for list fusion, but takeWhile, drop, and dropWhile are not. Is there
| > any reason for this discrepancy?
| >
| > If not, would I need to go through the l
GHCi does this somehow, so it's definitely possible; Simon M will know.
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of wren ng thornton
| Sent: 06 December 2011 17:49
| To: GHC-users List
| Su
| >> Trouble is, what type does this have?
| >> f x = x {}
| >>
| >> Malcolm Wallace wrote:
| > f :: a -> a
| >>
| >> Ian Lynagh wrote:
| That wouldn't help the original poster, as it is incompatible with
| f :: Foo Clean -> Foo Dirty
There are several different thing
Serge
I'm afraid I don't really follow your proposal in detail, but I think it may be
a version of the proposal described here
http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances
Perhaps you could see if the design there would meet your goals.
Simon
| -Original Mess
| > > Trouble is, what type does this have?
| > >
| > > f x = x {}
| >
| > f :: a -> a
|
| That wouldn't help the original poster, as it is incompatible with
| f :: Foo Clean -> Foo Dirty
Ah! *That* is why I said it was awkward. Thanks Ian.
Simon
___
| To: Malcolm Wallace
| Cc: GHC-users List
| Subject: Re: Why not allow empty record updates?
|
| Simon Peyton-Jones wrote:
| >> Trouble is, what type does this have?
| >> f x = x {}
|
| Malcolm Wallace wrote:
| > Empty record patterns {} are permitted, even for types
| > tha
Trouble is, what type does this have?
f x = x {}
In your example the type annotations give the clue, but Haskell is mainly
designed for type annotations to be optional. We require at least one field so
we can figure out, from the field name, which type is being updated.
Yes, something
Wolfgang
Is there a wiki page giving a specific, concrete design for the proposal you
advocate? Something at the level of detail of
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields?
I am unsure whether you regard it as an alternative to the above, or something
that shou
Wolfgang
Dimitrios, Stephanie and I spent a long time trying to come up with a decent
story for impredicative polymorphism (which would let you use types like
[forlall a. a->a]), wrote several papers about it, and even implemented one
version in GHC (hence -XImpredicativeTypes).
However the im
Thanks; fixed
From: sean.leat...@gmail.com [mailto:sean.leat...@gmail.com] On Behalf Of Sean
Leather
Sent: 22 October 2011 16:24
To: GHC Users List
Cc: Simon Peyton-Jones
Subject: :kind broken in HEAD
It seems like :kind is broken in the HEAD ghci:
*Main> :kind Maybe
Top level:
Expect
| Subject: Re: Records in Haskell
|
| I have added my proposal to the wiki.The only downsides to it that I can see
are:
Thanks to Barney for articulating a proposal for records in Haskell. Over
various plane rides and ICFP chats I've worked out some more details. It's not
as simple as I'd ho
n't think we can steal "group" as a keyword -- it's a function exported by
Data.List, and I don't think the benefit justifies the cost.
Simon
From: George Giorgidze [mailto:giorgi...@gmail.com]
Sent: 10 October 2011 23:22
To: Simon Peyton-Jones; GHC Users List; Phili
Paul
Always switch on -dcore-lint; it's a self-checker for types, and usually nails
an error much closer to the source.
Simon
From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Paul Monday
Sent: 16 October 2011 16:54
To: glasgow-hask
Roman, Jan-Willem
I'm maxed out at the moment, and will be so for at least a week.
If you think there is something mysterious and J-W agrees, could you create a
ticket, with the smallest example you can, and instructions to reproduce?
That'd be brilliant.
Of course, Jan-Willem, if you have a
Did you try 7.2? As I mentioned, the issue should have gone away entirely
because there is no shared cache any more
Simon
From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Jean-Marie
Gaillourdet
Sent: 12 October 2011 07:19
To: wagn
Greg
In GHC, big cases are done as tables (if dense) or trees (if sparse). If you
have some examples where things go bad, do submit a bug report.
For big dispatches on strings, I'm pretty sure we do something linear, top to
bottom. I'd be strongly inclined to use a proper Map structure if yo
Thank you for the detailed investigation. I have not followed all the details
of this thread, but I think that it may (happily) represent a bug in generating
TypeReps that is already fixed.
· We used to have a global cache from which we generated unique Int
keys corresponding to type
| In the spirit of "don't let the perfect be the enemy of the good"
| though, I'm solidly in favor of the original proposal as it is.
This is my thought too. George is proposing to extend Haskell's existing
mechanism for numeric literals (namely, replace 4 by (fromInteger
(4::Integer))), so
y salary
But that is hardly beautiful either.
So the current story is not great, but it's the best I could think of.
Improvements welcome.
Simon
| -Original Message-
| From: Philip Wadler [mailto:wad...@inf.ed.ac.uk]
| Sent: 04 October 2011 18:15
| To: Simon Peyton-Jones
I like both George's proposals.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of George Giorgidze
| Sent: 30 September 2011 18:28
| To: glasgow-haskell-users@haskell.org
| Subject: Two Proposals
| Sent: 03 October 2011 14:43
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users@haskell.org
| Subject: RE: mkTopLevEnv: not interpreted main:Main
|
| Thanks, Simon.
|
| I will work on building a smaller complete test case that reproduces the
| issue, and I could have done a better job of at lea
Combining lambdas makes a big difference in GHC. For example
f = \x. let y = E in \z. BODY
The function f takes one argument, and returns a heap-allocated lambda. If E
is cheap (say just a constructor) it might well be more efficient to transform
to
f = \xz. let y = E in BODY
Pa
I don't have a good answer here. FWIW
* I believe that the only call to mkTopLevEnv is in
InteractiveEval.findGlobalRdrEnv,
which in turn only calls mkTopLev on imports which are specified by an
IIModule
specification (see HscTypes.InteractiveImport).
* I think that IIModule things should
| With regard to [1], default superclass instances, is there already a plan to
| implement them? And if so, when is it expected to be finished?
|
| [1] http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances
It definitely won't be in 7.4 I'm afraid.
One thing that would be motiv
Yes, it expands type synonyms too
S
From: sean.leat...@gmail.com [mailto:sean.leat...@gmail.com] On Behalf Of Sean
Leather
Sent: 23 September 2011 13:43
To: Simon Peyton-Jones
Cc: GHC Users List
Subject: Re: Evaluating type expressions in GHCi
Hi Simon,
*TF> :kind F Int
F Int :: *
*TF>
I did this.
*TF> :kind F Int
F Int :: *
*TF> :kind! F Int
F Int :: *
= Bool
In the end I just made an eager version of :kind as the command: in addition to
displaying the kind of the type, it normalises it and shows the result.
It's in HEAD. Documentation to come when I get home.
I'
Sean
Yes, this has been asked for before, and it wouldn't be hard to implement.
What should the GHCi command be *called*?
We already have :kind, which displays the kind of a type. Maybe :kind! should
evaluate the type as well? Or perhaps :kind should evaluate anyway (although
that would be
all means have a go!
S
|
| On 16/09/2011 08:21, Simon Peyton-Jones wrote:
| > The difficulty here is that the TH library, by design, doesn't depend on
GHC. So
| we can't have a TH function
| > getFlags :: Q DynFlags
| > or (as you suggest, more or less)
| > runT
| > If you get it to work, I'd appreciate detailed (Windows is so far utterly
| > incomprehensible to me, so they'd better be very explicit) instructions.
| >
|
| I feel your pain. The Windows instructions could definately use some
| updating. :)
|
| I ended up getting an error during stage 2 abo
The difficulty here is that the TH library, by design, doesn't depend on GHC.
So we can't have a TH function
getFlags :: Q DynFlags
or (as you suggest, more or less)
runTc :: TcM a -> Q a
because to write those type signatures in Language.Haskell.TH.Syntax you'd need
to import GH
J Garrett Morris asked me
| I also rather like the TDNR proposal, as it's rather similar to the
| approach we're taking in Habit (our pet language at Portland State).
| However, I'm curious as to why you don't want to quantify over name
| resolution constraints. For example, why shouldn't:
|
| x
Friends
Provoked the (very constructive) Yesod blog post on "Limitations of Haskell",
and the follow up discussion, I've started a wiki page to collect whatever
ideas we have about the name spacing issue for record fields.
http://hackage.haskell.org/trac/ghc/wiki/Records
As Sim
| Yeah. I would expect this to work:
|
| inferBar2 :: Name -> Q [Dec]
| inferBar2 typeName =
|[d| instance Bar $(conT typeName) where
| bar _ = "sucker"
| |]
|
| But I get the same error:
|
| inferBar2 'Bool
|==>
| show-test.hs:4:3-18
| instance Bar Bool
[Redireting to ghc users; the TH list is pretty dormant and I keep thinking I
should close it down altogether.]
Jeremy
Actually this is by design. See the long thread at
http://hackage.haskell.org/trac/ghc/ticket/5375
When you say
| inferBar typeName =
|do s <- [d| bar _ = "sucker"
|
Too many words! I'm losing track. What I'm proposing is Option 2 under "The
design of the opt-out mechanism" on
http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances
I believe that meets everyone's goals:
* A warning encourages you to fix the client code
* But you can turn it
ginal Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Sebastian Fischer
| Sent: 30 August 2011 03:49
| To: Bas van Dijk
| Cc: glasgow-haskell-users@haskell.org; Simon Peyton-Jones
| Subject: Re: Superclass defaults
|
| On
Feel free to propose better solutions.
The underlying issue is that before type checking GHC (obviously) doesn't know
the types of things, while afterwards it does. The whole HsSyn tree is
parameterised over the types of identifiers:
Parsed: HsExpr RdrNames
Renamed: HsExpr Name
| > I don't completely understant how does it work. Does client need to enable
| > language extension to get default instances?
|
| I think that the extension would only be required to *define them*,
| not for them to be generated. The more conservative choice would
| indeed be to require the exte
gust 2011 18:14
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users
| Subject: Re: Can't find interface-file declaration for type constructor or
class
| integer-gmp:GHC.Integer.Type.Integer
|
| On Thu, Aug 18, 2011 at 7:07 PM, Simon Peyton-Jones
| wrote:
| > | I shouldn't have
| I shouldn't have to modify PrelNames since I kept GHC.Integer.Type,
| no? Or does PrelNames have to contain the name of the module that
| originally defined the type?
Yes, exactly!
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@
My guess is that you have not updated compiler/prelude/PrelNames, which
contains wired-in knowledge of which modules certain functions and data types
live in. Check the ones you've moved!
S
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-u
It's wrong. Thank you for pointing this out. I'll investigate.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Luite Stegeman
| Sent: 16 August 2011 16:57
| To: glasgow-haskell-users@haskell.or
| > If someone felt able to act as moderator for the discussion, willing
| > to summarise conclusions, open questions, and so on, on the wiki
| > page, that would be enormously helpful.
|
| I'm up for that role, if that's appropriate.
I'll take you up on that, thank you! I've added some "SLPJ n
(Adding GHC users, and changing title.)
| Conor McBride wrote:
| > http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances
| > I don't know if it's likely to be implemented in GHC anytime soon,..
| > So things are looking up. It should soon be technically feasible to
| > separate the i
Sigh. See http://hackage.haskell.org/trac/ghc/ticket/5398#comment:1
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Bas van Dijk
| Sent: 09 August 2011 13:47
| To: glasgow-haskell-users@haskel
In TH code you now need to use "mkName" at variable uses instead of the names
created directly with "newName". Repa had a similar problem.
Eh? I don't understand that. Can you give a small example?
Simon
From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@has
No, it's more #5375 and #5307. Email coming
S
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Sergei Trofimovich
| Sent: 09 August 2011 14:15
| To: Bas van Dijk
| Cc: glasgow-haskell-users@haskell.o
| > So then parseDynamicFlags should be split into two layers, the lower
| > layer returning unused flags, and the upper layer generating errors.
|
| It's not that simple. In
| ghcjs -O -someflag something -Wall
| is "something" an argument to someflag, or a file to be compiled?
It think it w
| data LiteralDesugaring m =
|LiteralDesugaring
| { desugarInt :: MonadThings m => Integer -> m CoreExpr
| , desugarWord :: MonadThings m => Integer -> m CoreExpr
...
I am not sure why you want to control the desugaring of literals. Why
literals? And why is literals enough?
| B
| I had a bit of fun recently tracking down quoting issues with the
| "system" command in Windows. For the examples below, I'll consistently
| use "Windows> " as the beginning of some text sent to the Windows
| command prompt cmd.exe, and use "GHC> " as the beginning of some text
| sent to a ghci s
Victor
GHC is supposed to be extensible, via its API, so your questions are good ones.
However, there are things that that the API doesn't support, or supports
badly, so it is not cast in stone. Please suggest improvements -- and better
still implement them. GHC evolves largely in response to
Dear Template Haskell users
There was a little exchange about TH quasiquotes a few weeks back (see below).
I've made a ticket and some concrete proposals here
http://hackage.haskell.org/trac/ghc/ticket/5348
Do take a look, if you care about TH quasiquotes.
Simon
| -Original Messag
com]
Sent: 22 July 2011 20:07
To: Simon Peyton-Jones
Cc: Gábor Lehel; glasgow-haskell-users@haskell.org
Subject: Re: Superclass Cycle via Associated Type
2011/7/22 Simon Peyton-Jones
mailto:simo...@microsoft.com>>
I talked to Dimitrios. Fundamentally we think we should be able to handle
I talked to Dimitrios. Fundamentally we think we should be able to handle
recursive superclasses, albeit we have a bit more work to do on the type
inference engine first.
The situation we think we can handle ok is stuff like Edward wants (I've
removed all the methods):
class LeftModule Whol
You point is that the (C Int) dictionary has (C String) as a superclass, and (C
String) has (C Int) as a superclass. So the two instances are mutually
recursive, but that's ok.
That is not unreasonable. But it is dangerous. Consider
class C [a] => C a
Then any dictionary for (C a) would
| iterIO uses mkTyCon for the simple reason that ((Typeable t, Typeable
| m) => Iter t m) is Typeable1 and there is no automatic way of deriving
| Typeable1.
This email is triggered by a thread on Haskell Cafe about changes to the
Typeable class
http://www.mail-archive.com/haskell-cafe@haskel
I believe that's right.
Simon
| -Original Message-
| From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-bugs-
| boun...@haskell.org] On Behalf Of Serge D. Mechveliani
| Sent: 23 June 2011 11:03
| To: glasgow-haskell-b...@haskell.org
| Cc: glasgow-haskell-users@haskell.
ll if it's
important to you.
There is a ticket about it: http://hackage.haskell.org/trac/ghc/ticket/4310, so
add yourself to the cc list if you care about it.
Simon
| -Original Message-
| From: Stefan Holdermans [mailto:ste...@vectorfabrics.com]
| Sent: 21 June 2011 10:51
| To: Simon Pe
Friends
I have long advertised a plan to allow so-called superclass equalities. I've
just pushed patches to implement them. So now you can write
class (F a ~ b) => C a b where { ... }
This email is just to encourage you to try them out.
Currently this is just in the HEAD git reposi
Friends, this is to ask your opinion about a possible change in GHC 7.2. The
current implementation in GHC 7.2 is Plan A below. Plan A is a bit easier for
us, but I think it may be a bit draconian, and therefore propose Plan B as an
alternative. Opinions?
Simon
=
thers?
Simon
| -Original Message-
| From: Edward Z. Yang [mailto:ezy...@mit.edu]
| Sent: 14 June 2011 14:04
| To: glasgow-haskell-users; Simon Peyton-Jones
| Subject: Re: MonoLocalBinds and hoopl
|
| I ran into some more code like this, and I realized there was something
| pretty important
Following Bryan's suggestion I've improved GHC's error message when there's a
module cycle:
Module imports form a cycle:
module `Foo4' imports `Foo'
which imports `Foo2'
which imports `Foo3'
which imports `Foo4'
Simon
| -Original
Great, thanks. I've added that link to the user-documentation page for the GHC
API, here
http://haskell.org/haskellwiki/GHC/As_a_library#Links
Please do elaborate that page, which is a bit thin at the moment. It should be
easier to find supporting info about the GHC API.
Simon
| -
--Original Message-
| From: Johan Tibell [mailto:johan.tib...@gmail.com]
| Sent: 09 June 2011 12:06
| To: Simon Peyton-Jones
| Subject: The role of INLINE and INLINABLE on recursive functions
|
| Hi,
|
| This comment on Trac got me curious:
|
| "Ok, we looked at this, and it turns out that 6
| > tcRnExpr :: HscEnv
| > -> InteractiveContext
| > -> LHsExpr RdrName
| > -> IO (Messages, Maybe Type)
| >
| > from TcRnDriver?
|
|
| This is pretty close to what I need. Unfortunately, I have
| LhsExpr Id not RdrName.
Just to be clear
LHsExpr RdrNameis just after
Maybe you want
tcRnExpr :: HscEnv
-> InteractiveContext
-> LHsExpr RdrName
-> IO (Messages, Maybe Type)
from TcRnDriver?
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of
|hpc_markup_multi_001(normal)
|hpc_markup_multi_002(normal)
|hpc_markup_multi_003(normal)
| Unexpected passes:
|mc01(hpc,ghci)
|mc06(hpc,ghci)
|mc08(hpc,ghci)
|mc11(hpc)
|mc16(hpc)
|mc18(hpc)
I pushed patches for all of these today
| Summing up: Yay!
Indeed!
Dear haskell.org committee
Great stuff. Thanks for getting this together.
Things I wondered about are:
- who will run the haskell.org entity?
- how are they chosen? do they have fixed terms?
- how are they accountable to the Haskell Community
(eg an a brief an
| cmm/CmmLex.x) to understand textual C--. Note that there is also a "new" C--
| representation hanging around that is not too interesting for you, since we
don't
| use it at all without the flag -fnew-codegen.
Although ultimately we hope to move to the new rep and abandon the old one.
Simon
301 - 400 of 1599 matches
Mail list logo
