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.
Rega
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 whe
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, ins
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 wrote:
> 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
___
H
Alexander Kjeldaas gmail.com> writes:
cabal install --upgrade-dependencies `eval echo $(ghc-global-constraints
)`
for a moment I was reading "ghc --global-constraints" there ... - J.W.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http:
Kim-Ee Yeoh 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: /usr/lib/ghc-7.4.2/
On Thu, Apr 25, 2013 at 6:38 AM, harry 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 its type signatur
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 c
Brandon Allbery 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" complicates thin
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:
http://
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
___
Ha
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 s
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 work
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 :: DBoo
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
Haskell-Cafe@ha
Good point, again. Is that the only problem with it?
On Thu, Apr 25, 2013 at 5:57 PM, Dan Doel 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 :: C a =
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
> >
> 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 =
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 w
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 possibilit
Conal Elliott 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 imperative pa
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 abov
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 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 data to their unbox
On 26/04/2013, at 2:15 PM, Johan Tibell wrote:
> Hi Ben,
>
> On Thu, Apr 25, 2013 at 7:46 PM, Ben Lippmeier 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
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 in
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 an
On Thu, Apr 25, 2013 at 10:30 PM, Andrew Cowie
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 unless told to
> be lazy
On Thu, Apr 25, 2013 at 9:20 PM, Ben Lippmeier 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 wrote:
>>> The Repa plugin will also do proper SIMD vectorisation for stream programs,
>>> producing the SIMD primops that Ge
32 matches
Mail list logo