(->) not working too well...

Samuel Bronson

17 Mar 2008 17 Mar '08

3:11 a.m.

This fails horribly in Jhc: {-# OPTIONS_NHC98 --prelude #-} ----------------------------------------------------------------------------- -- | -- Module : Control.Monad.Instances -- Copyright : (c) The University of Glasgow 2001 -- License : BSD-style (see the file libraries/base/LICENSE) -- -- Maintainer : libraries@haskell.org -- Stability : provisional -- Portability : portable -- -- 'Functor' and 'Monad' instances for @(->) r@ and -- 'Functor' instances for @(,) a@ and @'Either' a@. module Control.Monad.Instances (Functor(..),Monad(..)) where import Prelude instance Functor ((->) r) where fmap = (.) instance Monad ((->) r) where return = const f >>= k = \ r -> k (f r) r instance Functor ((,) a) where fmap f (x,y) = (x, f y) instance Functor (Either a) where fmap _ (Left x) = Left x fmap f (Right y) = Right (f y)

Show replies by date

John Meacham

17 Mar 17 Mar

4:03 p.m.

yeah, that doesn't surprise me that much, though it will likely be not too hard to fix. basically, since we need to sometimes treat types as values we can scrutinize (->) has a reified form of the type constructor that takes two arguments named Jhc@.-> defined in Name.Names as tc_Arrow. Code just needs to make sure that it translates between the two forms as needed. John -- John Meacham - ⑆repetae.net⑆john⑈

Samuel Bronson

10:32 p.m.

On 3/17/08, John Meacham wrote:

...

yeah, that doesn't surprise me that much, though it will likely be not too hard to fix. basically, since we need to sometimes treat types as values we can scrutinize (->) has a reified form of the type constructor that takes two arguments named Jhc@.-> defined in Name.Names as tc_Arrow.

Code just needs to make sure that it translates between the two forms as needed.

That's easy for you to say... but JHC doesn't seem to get the kind right on (->) at this point...

John Meacham

11:01 p.m.

On Mon, Mar 17, 2008 at 05:32:01PM -0400, Samuel Bronson wrote:

...

On 3/17/08, John Meacham wrote:

...
yeah, that doesn't surprise me that much, though it will likely be not too hard to fix. basically, since we need to sometimes treat types as values we can scrutinize (->) has a reified form of the type constructor that takes two arguments named Jhc@.-> defined in Name.Names as tc_Arrow.

Code just needs to make sure that it translates between the two forms as needed.

That's easy for you to say... but JHC doesn't seem to get the kind right on (->) at this point...

Well, the kind of (->) is fairly tricky due to the fact it is kind-polymorphic for the same reason it is in ghc. since functions need to accept unboxed arguments and return unboxed tuples. Though, restraining it to * -> * -> * in class heads probably makes sense. John -- John Meacham - ⑆repetae.net⑆john⑈

Samuel Bronson

11:32 p.m.

On 3/17/08, John Meacham wrote:

...

On Mon, Mar 17, 2008 at 05:32:01PM -0400, Samuel Bronson wrote:

...
On 3/17/08, John Meacham wrote:

...
yeah, that doesn't surprise me that much, though it will likely be not too hard to fix. basically, since we need to sometimes treat types as values we can scrutinize (->) has a reified form of the type constructor that takes two arguments named Jhc@.-> defined in Name.Names as tc_Arrow.

Code just needs to make sure that it translates between the two forms as needed.

That's easy for you to say... but JHC doesn't seem to get the kind right on (->) at this point...

Well, the kind of (->) is fairly tricky due to the fact it is kind-polymorphic for the same reason it is in ghc. since functions need to accept unboxed arguments and return unboxed tuples.

Though, restraining it to * -> * -> * in class heads probably makes sense.

I'm trying an explicit declaration in Jhc.Basics (yes, I changed the name to be a name in Jhc.Basics instead of Jhc@ everywhere...)

John Meacham

11:44 p.m.

Hrmm... that might not work so well. We actually need the kind overloaded sort for (->) and I wouldn't want an incorrect definition there. No matter what some treating of it specially will have to happen in the code proper, the internal representation of (->) just isn't a data constructor. (a -> b) is actually shorthand for π(_∷a).b John -- John Meacham - ⑆repetae.net⑆john⑈

Samuel Bronson

11:48 p.m.

On 3/17/08, John Meacham wrote:

...

Hrmm... that might not work so well. We actually need the kind overloaded sort for (->) and I wouldn't want an incorrect definition there. No matter what some treating of it specially will have to happen in the code proper, the internal representation of (->) just isn't a data constructor. (a -> b) is actually shorthand for π(_∷a).b

Eh? I've never seen any πs in Hs code... in any case, I wrote this: data (->) :: ?? -> ? -> * which has the right kind. If the kind inference engine can't handle this, this probably won't ever work right...

John Meacham

11:53 p.m.

On Mon, Mar 17, 2008 at 06:48:46PM -0400, Samuel Bronson wrote:

...

On 3/17/08, John Meacham wrote:

...
Hrmm... that might not work so well. We actually need the kind overloaded sort for (->) and I wouldn't want an incorrect definition there. No matter what some treating of it specially will have to happen in the code proper, the internal representation of (->) just isn't a data constructor. (a -> b) is actually shorthand for π(_∷a).b

Eh? I've never seen any πs in Hs code... in any case, I wrote this:

data (->) :: ?? -> ? -> *

which has the right kind. If the kind inference engine can't handle this, this probably won't ever work right...

Oh, it can handle it internally, I just wasn't sure if the front end actually handled that declaration properly. but if it is.. then super. There is a built in declaration in 'DataConstructors.hs' for tc_Arrow you will likely have to take out. which is a good thing if this works. John -- John Meacham - ⑆repetae.net⑆john⑈

Samuel Bronson

18 Mar 18 Mar

12:05 a.m.

On 3/17/08, John Meacham wrote:

...

On Mon, Mar 17, 2008 at 06:48:46PM -0400, Samuel Bronson wrote:

...
On 3/17/08, John Meacham wrote:

...
Hrmm... that might not work so well. We actually need the kind overloaded sort for (->) and I wouldn't want an incorrect definition there. No matter what some treating of it specially will have to happen in the code proper, the internal representation of (->) just isn't a data constructor. (a -> b) is actually shorthand for π(_∷a).b

Eh? I've never seen any πs in Hs code... in any case, I wrote this:

data (->) :: ?? -> ? -> *

which has the right kind. If the kind inference engine can't handle this, this probably won't ever work right...

Oh, it can handle it internally, I just wasn't sure if the front end actually handled that declaration properly. but if it is.. then super. There is a built in declaration in 'DataConstructors.hs' for tc_Arrow you will likely have to take out. which is a good thing if this works.

Of course it didn't! But that's easier than understanding all this kind stuff, or in any case than special-casing.

John Meacham

12:10 a.m.

On Mon, Mar 17, 2008 at 07:05:50PM -0400, Samuel Bronson wrote:

...

...
Oh, it can handle it internally, I just wasn't sure if the front end actually handled that declaration properly. but if it is.. then super. There is a built in declaration in 'DataConstructors.hs' for tc_Arrow you will likely have to take out. which is a good thing if this works.

Of course it didn't! But that's easier than understanding all this kind stuff, or in any case than special-casing.

Yes. certainly. I just hadn't realized I implemented that. (apparently not fully). but moving (->) to a real declaration is certainly the right thing to do. I have been slowly but surely eradicating all the special case code/predeclared stuff I can in jhc. John -- John Meacham - ⑆repetae.net⑆john⑈