Not sure if anyone else is using this, but I've fixed some bugs and
bumped fix-imports by a few more versions.
Here's copy paste from the package description:
A small standalone program to manage the import block of a haskell
program. It will try to add import lines for qualified names with no
On 12 July 2011 16:09, Evan Laforge qdun...@gmail.com wrote:
Not sure if anyone else is using this, but I've fixed some bugs and
bumped fix-imports by a few more versions.
Here's copy paste from the package description:
A small standalone program to manage the import block of a haskell
On Mon, Jul 11, 2011 at 11:48 PM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
A small standalone program to manage the import block of a haskell
program. It will try to add import lines for qualified names with no
corresponding import, remove unused import lines, and sort the import
I wrote:
Please respond to this thread if you own a package
that will be affected by this change.
Responding to my own request, here are some more
packages that use mkTyCon explicitly:
Ashley Yakeley's time package, which is part of the
Haskell Platform.
My timezone-series package, because it
On 12 July 2011 17:18, Evan Laforge qdun...@gmail.com wrote:
On Mon, Jul 11, 2011 at 11:48 PM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
A small standalone program to manage the import block of a haskell
program. It will try to add import lines for qualified names with no
I meant more in the Before: ... After: ... sense ;-) (i.e. visually
being able to tell what your program does, rather than just a
description).
Oh, ok, I guess I can do that too:
Before:
module M where
import ZZ.Out.Of.Order
import qualified No.Longer.Needed as Needed
-- x = Needed.y --
Generally allowing trailing (or leading or repeated) commas would clash
with tuple sections. Also the pair constructor (,) is a special case.
http://www.haskell.org/ghc/docs/7.0.4/html/users_guide/syntax-extns.html#tuple-sections
Cheers Christian
Am 11.07.2011 12:09, schrieb Joachim Breitner:
Carl Howells chowe...@janrain.com writes:
This will affect snap-core and heist, of the things I've provided
Typeable instances for.
In snap-core, deriving makes it use the internal module name, rather
than the canonical location of the type. This causes issues with the
Hint library, so
Hi James, I think you meant to reply to the list.
For one, I wouldn't consider GUI programming based on HTML as
declarative, since more often than not, the format says nothing about
its behavior, and when it does, it's through javascript, which is
hardly declarative.
Regards,
Paul Liu
On Tue,
Jon Fairbairn wrote:
There’ll be a replacement for mkTycon (mkTycon3), so you can
still do manual instances…
Right, it should be easy to fix manual Typeable instances.
It's just that if no action is taken, they will eventually break.
So it's good to make sure that there is public awareness,
and
On 07/07/2011 08:41, Simon Marlow wrote:
On 06/07/2011 21:19, Jason Dagit wrote:
On Wed, Jul 6, 2011 at 12:52 PM, Simon Marlowmarlo...@gmail.com wrote:
On 06/07/11 17:14, David Barbour wrote:
On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlowmarlo...@gmail.com
mailto:marlo...@gmail.com wrote:
On
-- unification-fd 0.5.0
The unification-fd package offers generic functions for first-order
structural unification (think Prolog programming or Hindley--Milner type
inference). I've had this laying around
This post is in literate Haskell. It describes how certain performance leaks
are introduced in type level programming. These leaks do not affect program
runtimes, but can cause compile times to grow drastically. They exist both with
Functional Dependencies and Type Families, but are currently
Dear Gershom,
Just to say many thanks for the extremely useful test cases! We will
investigate further.
Best,
Dimitris
-Original Message-
From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
users-boun...@haskell.org] On Behalf Of Gershom Bazerman
Sent: 12
On Tue, Jul 12, 2011 at 5:30 AM, Jon Fairbairn
jon.fairba...@cl.cam.ac.uk wrote:
So, this change will hit me for two different reasons, and sadly
involve using CPP to control how things are compiled.
so that shouldn’t be necessary.
CPP will be necessary, since we want to support older
Hi all,
Is there something wrong with the code below? My anticipation was that the
type of test would include the class constraint, because it uses the
Assign constructor. But if you load this code in GHCI you can see that the
inferred type was test :: E m - E m.
Thanks,
-Ryan
{-# LANGUAGE
Hi Ryan,
Think of AssignCap as an extra argument packaged up with the Assign
constructor. When
you pattern match against Assign you make the AssignCap constraint *available*
for use in
the RHS of the pattern; so there's no need for quantification, you already have
the constraint
you want
On Tue, Jul 12, 2011 at 2:58 AM, Simon Marlow marlo...@gmail.com wrote:
I discovered the real reason we run statements in a separate thread: the
GHCi debugger. If the computation stops at a breakpoint, then we have to
save the context and resume GHCi, which can only be done if the computation
On 07/12/2011 05:01 PM, Ryan Newton wrote:
Hi all,
Is there something wrong with the code below? My anticipation was that
the type of test would include the class constraint, because it uses
the Assign constructor. But if you load this code in GHCI you can see
that the inferred type was test
As a dutiful package maintainer I just checked to make sure unification-fd
built correctly on Hackage. Unfortunately it didn't, and it gives this
inscrutable error log:
cabal: There is no package named unification-fd. Perhaps you need to run
'cabal update' first?
Something awry on
No problems here (OS X.6). Baffling, indeed.
On Jul 12, 2011, at 7:58 PM, wren ng thornton wrote:
As a dutiful package maintainer I just checked to make sure unification-fd
built correctly on Hackage. Unfortunately it didn't, and it gives this
inscrutable error log:
cabal: There is no
Hey! =)
ArrowChoice's (+++) documentation [1] says that this is in general
not a functor [1]. What does it mean for (+++) to be or not to be a
functor?
Cheers,
[1]
http://hackage.haskell.org/packages/archive/base/4.3.1.0/doc/html/Control-Arrow.html#v:-43--43--43-
--
Felipe.
On Tue, Jul 12, 2011 at 6:55 PM, Felipe Almeida Lessa
felipe.le...@gmail.com wrote:
ArrowChoice's (+++) documentation [1] says that this is in general
not a functor [1]. What does it mean for (+++) to be or not to be a
functor?
The same note is made for (***). If you review Ross
Thanks, that does help. Very clear description.
Any good ideas about how to tweak my example to do what was intended ;-)?
The desired goal was that everywhere I construct a value using the Assign
constructor, that the resulting value's type to be tainted by the AssignCap
constraint.
24 matches
Mail list logo
