I think --reinstall only reinstalls the package you are actually
installing, not the dependencies. You could try using a sandboxing
tool, like cabal-dev. Then you just do 'cabal-dev install', and when
you want to reinstall everything, you do 'rm cabal-dev/' to wipe the
sandbox and start over.
This is not what you asked for, but reinstalling *all
dependencies*probably isn't such a good idea, because ultimately some
dependencies are
shipped with GHC and you might not be able to reinstall them.
Here is a useful formula I developed to avoid cabal-hell and always *upgrade
* dependencies
If I understand correctly, the problem with datatype contexts is that if we
have e.g.
data Eq a = Foo a = Foo a
the constraint Eq a is thrown away after a Foo is constructed, and any
method using Foos must repeat Eq a in its type signature.
Why were these contexts removed from the language,
From what I have heard, they are completely subsumed by GADTs, which is
a stable enough extension that it was considered unimportant to save.
Your Foo would be something like this:
data Foo a where
Foo :: Eq a = a - Foo a
On 4/25/2013 6:38 AM, harry wrote:
If I understand correctly, the
On Thu, Apr 25, 2013 at 6:36 PM, Joe Quinn headprogrammingc...@gmail.comwrote:
data Foo a where
Foo :: Eq a = a - Foo a
is equivalent to
data Foo a = Eq a = Foo a
but is different from
data Eq a = Foo a = Foo a
(Yup, tripped up a few of us already!)
-- Kim-Ee
Alexander Kjeldaas alexander.kjeldaas at gmail.com writes:
cabal install --upgrade-dependencies `eval echo $(ghc-global-constraints
)` package-name
for a moment I was reading ghc --global-constraints there ... - J.W.
___
Haskell-Cafe mailing list
Kim-Ee Yeoh ky3 at atamo.com writes:
data Foo a where
Foo :: Eq a = a - Foo a
is equivalent to
data Foo a = Eq a = Foo a
but is different from
data Eq a = Foo a = Foo a
... and nothing in GADTs does what one would naively expect the last
declaration to do.
In trying to compile a 2 year old, previously working project on a new
machine with a fresh Haskell Platform installation, I bumped into this:
ghc -o libami.so -shared -package parsec -lHSrts -lm -lffi -lrt AMIParse.o
AMIModel.o ami_model.o ExmplUsrModel.o Filter.o
/usr/bin/ld:
On Thu, Apr 25, 2013 at 6:38 AM, harry volderm...@hotmail.com wrote:
If I understand correctly, the problem with datatype contexts is that if we
have e.g.
data Eq a = Foo a = Foo a
the constraint Eq a is thrown away after a Foo is constructed, and any
method using Foos must repeat Eq a in
I've wondered this too. What would have been wrong with a simple
source-to-source translation, where a constraint on the datatype itself
translates to the same constraint on each of its constructors? Perhaps it
would be unintuitive that you would have to pattern match before gaining
access to the
Brandon Allbery allbery.b at gmail.com writes:
As I understand it, it's because fixing them involves passing around a
dictionary along with the data, and you can't do that with a standard
declaration (it amounts to an extra chunk of data that's only *sometimes*
wanted, and that sometimes
Well-Typed are offering Haskell courses in the San Francisco Bay Area
and New York in early June.
They are for professional developers who want to learn Haskell or
improve their skills. There is a 2-day introductory course and a 2-day
advanced course.
Full course and registration details:
Dear all,
our next regular meeting will take place in Munich on the 29th of April
at 19h30 at Cafe Puck.
If you plan to join us, please go to
http://www.haskell-munich.de/dates
and click the button.
Until then, have a nice time,
Heinrich
___
It is not completely backwards compatible, because (for instance) the
declaration:
newtype C a = Foo a = Foo a
was allowed, but:
newtype Foo a where
Foo :: C a = a - Foo a
is an illegal definition. It can only be translated to a non-newtype data
declaration, which changes the
Hi,
suppose that there is following data family:
data family D a
data instance D Int = DInt Int
data instance D Bool = DBool Bool
it is not possible to match on constructors from different instances:
-- type error
a :: D a - a
a (DInt x) = x
a (DBool x) = x
however, following works:
At Thu, 25 Apr 2013 20:29:16 +0400,
Alexey Egorov wrote:
I'm curious - why data families constructors (such as DInt and DBool) doesn't
imply such constraints while typechecking pattern matching?
I think you are misunderstanding what data families do. ‘DInt :: DInt - D Int’
and ‘DBool :: DBool
At Thu, 25 Apr 2013 19:08:17 +0100,
Francesco Mazzoli wrote:
... ‘DInt :: DInt - D Int’ and ‘DBool :: DBool - D Bool’ ...
This should read ‘DInt :: Int - D Int’ and ‘DBool :: Bool - D Bool’.
Francesco
___
Haskell-Cafe mailing list
Good point, again. Is that the only problem with it?
On Thu, Apr 25, 2013 at 5:57 PM, Dan Doel dan.d...@gmail.com wrote:
It is not completely backwards compatible, because (for instance) the
declaration:
newtype C a = Foo a = Foo a
was allowed, but:
newtype Foo a where
Foo
At Thu, 25 Apr 2013 19:08:17 +0100,
Francesco Mazzoli wrote:
Would you expect this to work?
newtype DInt a = DInt a
newtype DBool a = DBool a
type family D a
type instance D Int = DInt Int
type instance D Bool = DBool Bool
a :: D a - a
a (DInt x) = x
a (DBool x) = x
Or
Would you expect this to work?
newtype DInt a = DInt a
newtype DBool a = DBool a
type family D a
type instance D Int = DInt Int
type instance D Bool = DBool Bool
a :: D a - a
a (DInt x) = x
a (DBool x) = x
Or even better:
data family D a
data instance D Int = DInt1 Int | DInt2
At Fri, 26 Apr 2013 00:20:36 +0400,
Alexey Egorov wrote:
Yes, my question is about why different instances are different types even if
they have the same type constructor (D).
I'm just find it confusing that using GADTs trick it is possible to match on
different constructors.
See it this way:
Let's look at it from the operational perspective.
In the GADT case, the set of possibilities is fixed in advance (closed).
Every GADT constructor has a corresponding tag (a small integer) which,
when pattern-matching, tells us which branch to take.
In the data family case, the set of
Conal Elliott co...@conal.net wrote:
I first tried an imperative push-based FRP in 1998, and I had exactly
the same experience as Heinrich mentions. The toughest two aspects of
imperative implementation were sharing and event merge/union/mappend.
This is exactly why I chose not to follow the
I can't think of any at the moment that are still in force. However, one
that might have been relevant at the time is:
data C a = Foo a = Foo a a
foo :: Foo a - (a, a)
foo ~(Foo x y) = (x, y)
Irrefutable matches used to be disallowed for GADT-like things, which would
break the above
On 4/25/13 9:49 PM, Dan Doel wrote:
I don't really think they're worth saving in general, though. I haven't
missed them, at least.
The thing I've missed them for (and what I believe they were originally
designed for) is adding constraints to derived instances. That is, if I
have:
data Bar
On 25/04/2013, at 3:47 AM, Duncan Coutts wrote:
It looks like fold and unfold fusion systems have dual limitations:
fold-based fusion cannot handle zip style functions, while unfold-based
fusion cannot handle unzip style functions. That is fold-based cannot
consume multiple inputs, while
Hi Ben,
On Thu, Apr 25, 2013 at 7:46 PM, Ben Lippmeier b...@ouroborus.net wrote:
The Repa plugin will also do proper SIMD vectorisation for stream programs,
producing the SIMD primops that Geoff recently added. Along the way it will
brutally convert all operations on boxed/lifted numeric
On 26/04/2013, at 2:15 PM, Johan Tibell wrote:
Hi Ben,
On Thu, Apr 25, 2013 at 7:46 PM, Ben Lippmeier b...@ouroborus.net wrote:
The Repa plugin will also do proper SIMD vectorisation for stream programs,
producing the SIMD primops that Geoff recently added. Along the way it will
2013-04-26 04:31, wren ng thornton skrev:
On 4/25/13 9:49 PM, Dan Doel wrote:
I don't really think they're worth saving in general, though. I haven't
missed them, at least.
The thing I've missed them for (and what I believe they were originally
designed for) is adding constraints to derived
On Thu, 2013-04-25 at 21:15 -0700, Johan Tibell wrote:
{-# LANGUAGE Strict #-}
God, I would love this. Obviously the plugin approach could do it, but
could not GHC itself just _not create thunks_ for things unless told to
be lazy in the presence of such a pragma?
[at which point, we need an
On Thu, Apr 25, 2013 at 10:30 PM, Andrew Cowie
and...@operationaldynamics.com wrote:
On Thu, 2013-04-25 at 21:15 -0700, Johan Tibell wrote:
{-# LANGUAGE Strict #-}
God, I would love this. Obviously the plugin approach could do it, but
could not GHC itself just _not create thunks_ for things
On Thu, Apr 25, 2013 at 9:20 PM, Ben Lippmeier b...@ouroborus.net wrote:
On 26/04/2013, at 2:15 PM, Johan Tibell wrote:
Hi Ben,
On Thu, Apr 25, 2013 at 7:46 PM, Ben Lippmeier b...@ouroborus.net wrote:
The Repa plugin will also do proper SIMD vectorisation for stream programs,
producing
32 matches
Mail list logo
