On Sun, Jun 01, 2008 at 01:46:43PM -0700, Don Stewart wrote:
Hello Serge,
I was looking at the cabal file used to build docon,
I note the current flags are:
ghc-options:
-fglasgow-exts -fallow-overlapping-instances
-fallow-undecidable-instances
Interesting
* I think it is a Bad Idea for an application to assume
that the implementation of (f^n) will not multiply by 1.
Implementations of numeric algorithms probably make all sorts
of ill-documented assumptions about the algebraic properties
of numeric operations
* On the other
Donn Cave wrote:
On Fri, 30 May 2008 10:43:22 -0400
Gregory Wright [EMAIL PROTECTED] wrote:
http://hackage.haskell.org/trac/ghc/attachment/ticket/2013/2013.patch
*BSD folks please test.
I built the 20080529 snapshot with this patch and my light testing of
ghci
showed no problems (FreeBSD
Gregory Wright wrote:
Hi,
On May 29, 2008, at 11:19 AM, Simon Marlow wrote:
Ok, I've now modified the patch and attached a new version to the
ticket:
http://hackage.haskell.org/trac/ghc/attachment/ticket/2013/2013.patch
*BSD folks please test.
I built the 20080529 snapshot with this
The May 2008 Haskell Communities and Activities Report, GHC
http://www.haskell.org/communities/05-2008/html/report.html#ghc:
Impredicative polymorphism. We are not happy with GHC’s current
implementation of impredicative polymorphism, which is rather
complicated and ad hoc. Dimitrios (with Simon
I wrote:
A side-effect is for those of us who want to have any concern for future
compatibility with non-GHC type systems (or the long future of GHC's,
even), whether one of the proposals would be likely to be easier for
someone else to implement in a different compiler.
actually, just as
Hi Christian,
On Sun, Jun 01, 2008 at 09:55:06PM +0200, Christian Höner zu Siederdissen wrote:
We now can compile into executable code some of these programs but the
compiler requires an incredible amount of memory: the 15,000 line
programs easily require 2 GByte of RAM and then the
Dreixel wrote:
Hello,
Does anyone know if it is possible to specify a default definition for an
associated type synonym? When I tried:
class A a where
type B a = a
GHC (version 6.9.20080309) told me: Type declaration in a class must be a
kind signature or synonym default. However, when I
Isaac,
Does anyone know if it is possible to specify a default definition
for an
associated type synonym?
According to http://hackage.haskell.org/trac/ghc/wiki/TypeFunctionsStatus
defaults for associated types is still a TODO.
Cheers,
Stefan
On Mon, 02 Jun 2008 09:36:41 +0100
Simon Marlow [EMAIL PROTECTED] wrote:
Unfortunately, it won't build with the GNU ar that's standard on this
platform. It can't index archives as big as libHSbase.a: apparently, it
allocates too many moderately large hash tables for the many small modules
10 matches
Mail list logo
