darcs patch: Get Data.Typeable to compile
Sun Mar 16 20:22:51 EDT 2008 Samuel Bronson
Hi, I don't want to use cpp ever more than strictly necessary, so, when using it, only put it on individual files with an {-# OPTIONS_JHC -fcpp #-} and and use {-# OPTIONS_JHC -N #-} for no implicit prelude. though, for unsafecoerce, I think just the following will do fine {-#OPTION_JHC -N #-} module Unsafe.Coerce(unsafeCoerce) where import Jhc.Prim unsafeCoerce = unsafeCoerce__ in general, almost all uses of CPP should be replaced by constant expressions when possible, like foo = if (sizeOf Int == 32) then foo32 else fooOther and for doing 'meta-programming' 'm4' is much nicer than CPP so I expect the main use of CPP will be in external libraries rather than any of the jhc built in ones. John -- John Meacham - ⑆repetae.net⑆john⑈
On Mon, Mar 17, 2008 at 4:09 AM, John Meacham
Hi, I don't want to use cpp ever more than strictly necessary, so, when using it, only put it on individual files with an
{-# OPTIONS_JHC -fcpp #-} and and use {-# OPTIONS_JHC -N #-} for no implicit prelude.
though, for unsafecoerce, I think just the following will do fine
{-#OPTION_JHC -N #-} module Unsafe.Coerce(unsafeCoerce) where import Jhc.Prim unsafeCoerce = unsafeCoerce__
in general, almost all uses of CPP should be replaced by constant expressions when possible, like
foo = if (sizeOf Int == 32) then foo32 else fooOther
and for doing 'meta-programming' 'm4' is much nicer than CPP so I expect the main use of CPP will be in external libraries rather than any of the jhc built in ones.
Well, I *did* copy and paste this from the main base repository, but I guess that *was* rather overkill in this instance since it doesn't share more than one line of actual code... out of three lines in the entire module. For other, less trivial modules from that source, it would be okay to use cpp, wouldn't it?
Well, it depends. Ideally what I want is for the 'jhc' distribution to contain just the haskell' libraries (once they are finalized) which will likely be much smaller than the current extended 'base' that ghc uses, so I don't want to get in the habit of importing code from the ghc repo in large quantities. that said, for practical reasons, and since a lot of the stuff in ghc base isn't separately packaged, I do need some way to make it available. I think what would be best is to have the current 'base' library just contain a fairly minimal base, what we expect to be in haskell' or what is jhc specific enough to be interesting.as well as what is enough to build 'haskell98'. then create another 'base-extras' library which will contain mostly unchanged code from the ghc repo that is in ghc's base. like System.Console.GetOpts can probably go there. John -- John Meacham - ⑆repetae.net⑆john⑈
On 3/17/08, John Meacham
Well, it depends. Ideally what I want is for the 'jhc' distribution to contain just the haskell' libraries (once they are finalized) which will likely be much smaller than the current extended 'base' that ghc uses, so I don't want to get in the habit of importing code from the ghc repo in large quantities.
that said, for practical reasons, and since a lot of the stuff in ghc base isn't separately packaged, I do need some way to make it available. I think what would be best is to have the current 'base' library just contain a fairly minimal base, what we expect to be in haskell' or what is jhc specific enough to be interesting.as well as what is enough to build 'haskell98'. then create another 'base-extras' library which will contain mostly unchanged code from the ghc repo that is in ghc's base. like System.Console.GetOpts can probably go there.
Wouldn't it be more sensible to put the JHC-specific code in a library called jhcbase, like hugs does (only of course theirs is called hugsbase or something), and just use the "base" repository that everyone else uses for the not-really-jhc-specific bits?
On Mon, Mar 17, 2008 at 03:52:28PM -0400, Samuel Bronson wrote:
that said, for practical reasons, and since a lot of the stuff in ghc base isn't separately packaged, I do need some way to make it available. I think what would be best is to have the current 'base' library just contain a fairly minimal base, what we expect to be in haskell' or what is jhc specific enough to be interesting.as well as what is enough to build 'haskell98'. then create another 'base-extras' library which will contain mostly unchanged code from the ghc repo that is in ghc's base. like System.Console.GetOpts can probably go there.
Wouldn't it be more sensible to put the JHC-specific code in a library called jhcbase, like hugs does (only of course theirs is called hugsbase or something), and just use the "base" repository that everyone else uses for the not-really-jhc-specific bits?
Well, I actually wanted 3 packages: jhc - nothing that relys on Prelude, everything the compiler needs or knows about is in here somewhere. as in, the compiler has no built in knowledge of anything that doesn't live in 'jhc'. should be fairly small. base - basic functionality, enough to implement one of the language standards, either haskell98, haskell' or one of the random alternate prelude systems that are floating about. base-extras (or some other name) - something just to fill out compatibility with ghc's base but stuff that wouldn't normally need to be distributed with a compiler. John -- John Meacham - ⑆repetae.net⑆john⑈
participants (2)
-
John Meacham -
Samuel Bronson