| Ah yes, silly me. What I had in mind, I suppose, was
| something more along the lines of:
|
| foo :: Double -> (exists q . Foo q => q)
Correct. Currently you can only express this by wrapping
the existential in a constructor:
data R = forall q. Foo q => MkR q
foo :: Double
Yes, and there will be one this year too. Tim Sheard is organising it.
Simon
| -Original Message-
| From: Tom Pledger [mailto:[EMAIL PROTECTED]]
| Sent: 05 April 2002 04:03
| To: [EMAIL PROTECTED]
| Subject: functional programming contest
|
|
| Andre W B Furtado writes:
| | I was vis
Andre W B Furtado writes:
| I was visiting http://www.ai.mit.edu/extra/icfp-contest/ and noticed that
| there was a functional programming contest in ICFP 98. I'd like to know if
| there are any periodic functional progamming contests around the world, such
| as the ACM contest for the C langu
I was visiting http://www.ai.mit.edu/extra/icfp-contest/ and noticed that
there was a functional programming contest in ICFP 98. I'd like to know if
there are any periodic functional progamming contests around the world, such
as the ACM contest for the C language.
-- Andre
__
On Thursday, April 4, 2002, 22:36 CET Hal Daume III wrote:
> Why can I not define the following (in ghc):
>
> > class Foo p where
> > instance Foo Double where
> > foo :: Double -> (forall q . Foo q => q)
> > foo p = p
>
> From my humble (lack of) knowledge, there seems to be nothing wrong here,
> > class Foo p where
> > instance Foo Double where
> > foo :: Double -> (forall q . Foo q => q)
> > foo p = p
>
> From my humble (lack of) knowledge, there seems to be nothing wrong
> here, but ghc (5.03) complains about unifying q with Double.
>
> Well, of
Why can I not define the following (in ghc):
> class Foo p where
> instance Foo Double where
> foo :: Double -> (forall q . Foo q => q)
> foo p = p
From my humble (lack of) knowledge, there seems to be nothing wrong
here, but ghc (5.03) co
Why can I not define the following (in ghc):
> class Foo p where
> instance Foo Double where
> foo :: Double -> (forall q . Foo q => q)
> foo p = p
>From my humble (lack of) knowledge, there seems to be nothing wrong here,
but ghc (5.03) complains about unifying q with Double. I *can* write:
>
On Wed, Apr 03, 2002 at 11:15:04AM -0800, Hal Daume III wrote:
> I'm looking for a (not-necessarily Haskell 98 compliant, as long as it
> works in GHC) way to get at the internal representation of Doubles. I can
> use decodeDouble# to get at it, but I need something equivalent to
> encodeDouble#
| > ...which would be very useful, but would probably have unpleasant
| > consequences for type inference...
|
| To my mind, this is not a credible objection. The horse has
| already bolted; there's no point in trying to shut the stable
| door. The existing post-Hindley-Milner aspects of Hask
Hi all,
> At 2002-04-03 15:14, Hal Daume III wrote:
> >> type FM = FiniteMap
> >> type FM a b = FiniteMap a b
> >
> >I wasn't aware there was (supposed to be) a difference
> >between these two declarations? Is there?
On Wed, 3 Apr 2002, Ashley Yakeley wrote:
> type FM a b = FiniteMap a b
>
[Apologies for multiple copies of this announcement]
**
final call for papers and participation ***
**
It's a bug in GHC 5.02 and earlier; fixed in 5.03
Simon
| -Original Message-
| From: Hal Daume III [mailto:[EMAIL PROTECTED]]
| Sent: 04 April 2002 00:15
| To: Haskell Mailing List
| Subject: deriving over renamed types
|
|
| Why can't I do this:
|
| > import FiniteMap
| > type FM =
13 matches
Mail list logo
