Yes, it's expected; it's also the behaviour of GHC 6.12 etc.
Here what is happening. You define
result = undefined
What type does it get? In 6.12, and 7.4, it gets type
result :: forall b. b
So the two uses of 'result' in the two branches of the case have no effect on
each
it’s a bug. I’m fixing it.
Simon
From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Edward Kmett
Sent: 22 December 2011 17:03
To: Bas van Dijk
Cc: glasgow-haskell-users@haskell.org
Subject: Re: ConstraintKinds and default associated
Dear GHC users
I've just discovered something very peculiar with unboxed tuples in GHC.
f2 x = (# True, False #)
f1 x = (# True #)
f0 x = (# #)
What types do these functions have?
f2 :: a - (# Bool, Bool #)
f1 :: a
On Fri, Dec 23, 2011 at 12:46:38PM +, Simon Peyton-Jones wrote:
Dear GHC users
I've just discovered something very peculiar with unboxed tuples in GHC.
The problem is that there is no boxed singleton tuple, whereas there is
an unboxed singleton tuple, so there is a conflict between the
Your table isn't quite right. For data constructors the current situation is
this:
Arguments Boxed Unboxed
3 ( , , )(# , , #)
2 ( , ) (# , #)
1 (# #)
0 ()
Wierd! Indeed, in my proposal, here is no singleton data
On Fri, Dec 23, 2011 at 01:34:49PM +, Simon Peyton-Jones wrote:
Arguments Boxed Unboxed
3 ( , , )(# , , #)
2 ( , ) (# , #)
1
0 () (# #)
Simple, uniform.
Uniform horizontally, but strange vertically!
Hi,
Am Mittwoch, den 21.12.2011, 18:29 + schrieb Ian Lynagh:
Please test as much as possible; bugs are much cheaper if we find them
before the release!
the build system seems to be quite confused on arch/os-combinations
besides {i386,amd64}/linux. All these worked fine with 7.2.2:
On Fri, Dec 23, 2011 at 3:04 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
Yes, it's expected; it's also the behaviour of GHC 6.12 etc.
Here what is happening. You define
result = undefined
What type does it get? In 6.12, and 7.4, it gets type
result :: forall b. b
So
| So the 'where' binding in the following does not get generalized
| because it could not have been written at the top level, correct?
The other way round. 'where' bindings that could have been written at top
level *are* generalised; ones that could not are *not* generalised. See Which
On 23/12/2011 13:46, Ian Lynagh wrote:
On Fri, Dec 23, 2011 at 01:34:49PM +, Simon Peyton-Jones wrote:
Arguments Boxed Unboxed
3 ( , , )(# , , #)
2 ( , ) (# , #)
1
0 () (# #)
Simple, uniform.
Uniform
On Fri, Dec 23, 2011 at 12:33 PM, Simon Peyton-Jones
simo...@microsoft.com wrote:
| So the 'where' binding in the following does not get generalized
| because it could not have been written at the top level, correct?
The other way round. 'where' bindings that could have been written at top
Fair enough.
So if I understand you correctly, () is becoming more overloaded as to its
kind?
Right now it seems it is either * or Constraint depending on context.
As I understand you, fixing this seems to indicate that () could have any 'a -
Constraint' kind as well.
This raises similar
Very hard to be generic over *unboxed* tuples!
But yes the non-uniformity in boxed tuples is annoying.
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of Ganesh Sittampalam
| Sent: 23 December 2011
On Fri, Dec 23, 2011 at 10:17 AM, Simon Peyton-Jones
simo...@microsoft.comwrote:
Right now it seems it is either * or Constraint depending on context. ***
*
** **
Correct. Tuple bracket are used for both types and Constraints, and we
have to decide which from context.
**
Whew,
My attempt at forming a new understanding was driven by your example.
class Functor f where
type C f :: * - Constraint
type C f = ()
sorry -- that was simply type incorrect. () does not have kind * - Constraint
S
From: Edward Kmett [mailto:ekm...@gmail.com]
Sent: 23 December 2011 16:41
Are Records stalled out again? I am perfectly willing to leave the fate of
records up to a willing and capable implementer. That seems much better than
waiting another 5 years for perfection :)
Yes, they are stalled again. The simple solution turned out to be not
simple. I wrote it up at
Hi,
I have to second that. I recently fell over that problem when writing
instances for certain kinds of tuples. In libraries, such as tuple
there is a special 'OneTuple' constructor but I'd really appreciate a
more uniform fix -- but don't know of one either...
Gruss,
Christian
* Ganesh
I am willing to help on this as much as I can. Unfortunately I don't think
you want me to lead the discussion or make decisions on this - many of
these discussions seem over my head. I will continue to study them though
and see if the sink in more.
I do think almost all of these proposals want a
On December 23, 2011 09:37:04 Ganesh Sittampalam wrote:
On 23/12/2011 13:46, Ian Lynagh wrote:
On Fri, Dec 23, 2011 at 01:34:49PM +, Simon Peyton-Jones wrote:
Arguments Boxed Unboxed
3 ( , , )(# , , #)
2 ( , ) (# , #)
1
0 () (#
Here are the kinds of the type constructors:
(,,) :: * - * - * - *
(,) :: * - * - *
() :: *
(# ,, #) :: * - * - * - #
(# , #) :: * - * - #
BUT
(# #) :: * - #
Just of out curiosity, what
One more code sample which compiled with GHC 7.2.1 and does not with the new RC:
{-# LANGUAGE FlexibleContexts, FlexibleInstances,
FunctionalDependencies, MultiParamTypeClasses, RankNTypes,
UndecidableInstances, TypeFamilies #-}
newtype MyMonadT m a = MyMonadT (m a)
class MyClass b m | m - b
I've noticed a strange behaviour with ghc's -osuf flag:
% cat Test.hs
{-# LANGUAGE ForeignFunctionInterface #-}
module Test where
import Foreign
foreign import ccall wrapper c_callback :: Int - IO (FunPtr Int)
% ghc-7.0.3 -v -c -osuf .hs.o Test.hs
% ls
Tes_stub.hs.o Test.hsTest_stub.c
22 matches
Mail list logo
