Hi,
When migrating some code with type families to GHC 6.10, I frequently get
the same error.
The deal is. If I define some type family and instance:
*type family Rep (f :: * - *) x :: *
data (g :+: h) x= Inl (g x) | Inr (h x)
type instance Rep (g :+: h) x = Rep g x `Either` Rep h x*
and
I've been using HSH with good results for sysadmin tasks, and recently
uploaded HSHHelpers to hackage.
Of course with Cpan a lot of stuff has already been done for you, but
that's a library issue.
Nothing beats bash for a quicky of course, but there a lot of ways to
shoot yourself in the foot
I was upgrading happstutorial.com to ghc 6.10.1 when I came across a
cabal install issue.
Somewhere in day 1 (probably as a HAppS dependency), HaXml 1.13.1 got installed.
On day 2, I wanted the latest version of HaXml (1.19.4), a dependency
for for xml-parsec.
cabal install HaXml gave me:
When I specify
Build-Depends: base, parsec, HaXml = 1.19.4
in xml-parsec.cabal
it does install correctly.
I guess what happens is that cabal install takes the earliest version
of a package registered to try to build. I guess that's a reasonable
default.
What seems unreasonable to me is that
On Sat, 2008-11-15 at 12:39 +0100, Thomas Hartman wrote:
When I specify
Build-Depends: base, parsec, HaXml = 1.19.4
in xml-parsec.cabal
it does install correctly.
Yes, saying what version it needs is a good thing. It's all guesses
otherwise.
I guess what happens is that cabal install
On Sat, 2008-11-15 at 02:26 +0100, Niklas Broberg wrote:
Fellow Haskelleers,
it is my pleasure to announce the new release of the haskell-src-exts
package, version 0.4.1:
2) ... I've finally decided to take the plunge and get rid of the ugly
prefixes on all datatypes in the AST. I am of
This is all news to me, and un-googleable to boot:
http://www.google.pl/search?hl=ensa=Xoi=spellresnum=0ct=resultcd=1q=cabal+referred-versionsspell=1
(no results)
So yes, I think this referred-versions machinery should at least be
made more transparent for situations when it does the wrong
Fellow Haskelleers,
it is my pleasure to announce the new release of the haskell-src-exts
package, version 0.4.1:
All looks great :-)
I upgraded my project using HSE, which made very heavy use of the
library, in about 15 minutes. And that included getting name 3 clashes
and fixing one abuse
Thomas Hartman wrote:
When I specify
Build-Depends: base, parsec, HaXml = 1.19.4
in xml-parsec.cabal
it does install correctly.
I just fixed xml-parsec.cabal and uploaded it on hackage:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xml-parsec-1.0.3
[...]
//Stephan
On Sat, 2008-11-15 at 13:31 +0100, Thomas Hartman wrote:
This is all news to me, and un-googleable to boot:
http://www.google.pl/search?hl=ensa=Xoi=spellresnum=0ct=resultcd=1q=cabal+referred-versionsspell=1
(no results)
It finds something for me (with the right spelling of preferred), eg
Any chance of including support for view patterns in a future release?
http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#view-patterns
. The project I'm writing using HSE makes significant use of view
patterns, and it would be lovely if I could be self applicable :-)
deduktionstheorem:
Thomas Hartman wrote:
When I specify
Build-Depends: base, parsec, HaXml = 1.19.4
in xml-parsec.cabal
it does install correctly.
I just fixed xml-parsec.cabal and uploaded it on hackage:
Hi,
I need to make the following structure into
an instance of Storable:
struct {
double w[2];
}
Can I assume that its function 'alignment' should
return the same as alignment (1::CDouble)? Or
should it be 2 * alignment (1::CDouble)?
(I've read the wikipedia article about memory alignment,
---
Haskell Weekly News
http://sequence.complete.org/hwn/20081115
Issue 93 - November 15, 2008
---
Welcome to issue 93 of HWN, a newsletter covering
Hello Maurício,
Saturday, November 15, 2008, 11:29:23 PM, you wrote:
struct {
double w[2];
}
Can I assume that its function 'alignment' should
return the same as alignment (1::CDouble)? Or
should it be 2 * alignment (1::CDouble)?
secind - definitely not. first - probably yes
--
If you are using hsc2hs (if you are using Cabal this is easy; just
rename the file to *.hsc and Cabal will take care of the rest), then
there is a macro for making this easier and so you don't have to think
about it.
First, place the following at the top of your source file:
#let alignment t =
Hello,
Has anyone already made a tool to check if exported functions, data
constructors, types, etc are unused within a set of modules?
For my usage it would probably suffice if the tool only compared
import lists against export lists as we compile with -Wall and 99% of
our imports say exactly
Hi all!
When working with Applicative, I often find myself defining and using
this operator:
(%) :: (Applicative f) = f (a - b) - a - f b
f % x = f * pure x
and always keep wondering whether it is already known by another name.
Can't find it in Control.Applicative. Hoogle didn't give me much
On Sat, Nov 15, 2008 at 3:59 PM, Ariel J. Birnbaum [EMAIL PROTECTED] wrote:
Hi all!
When working with Applicative, I often find myself defining and using
this operator:
(%) :: (Applicative f) = f (a - b) - a - f b
f % x = f * pure x
Yeah, me too.
The syntax chosen for applicative does not
Any chance of including support for view patterns in a future release?
http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#view-patterns
. The project I'm writing using HSE makes significant use of view
patterns, and it would be lovely if I could be self applicable :-)
On Sat, 2008-11-15 at 16:23 -0700, Luke Palmer wrote:
On Sat, Nov 15, 2008 at 3:59 PM, Ariel J. Birnbaum [EMAIL PROTECTED] wrote:
When working with Applicative, I often find myself defining and using
this operator:
(%) :: (Applicative f) = f (a - b) - a - f b
f % x = f * pure x
Yeah,
On Sun, Nov 16, 2008 at 12:59:09AM +0200, Ariel J. Birnbaum wrote:
When working with Applicative, I often find myself defining and using
this operator:
(%) :: (Applicative f) = f (a - b) - a - f b
f % x = f * pure x
and always keep wondering whether it is already known by another name.
f
22 matches
Mail list logo