Hello,

my preference would be to build this kind of functionality (and other related features) in libraries on top of GHC.TypeLits.  This modules was intended to contain only a minimal set of the constants that the compiler needs to know about, and it already may have too much in it.

On the concrete issue:  orphan instances could be avoided if the type lits instances are defined in the same module as the class.

-Iavor


On Thu, Feb 7, 2013 at 6:50 AM, Gabor Greif <ggreif@gmail.com> wrote:
In its current state it is not tied to TypeLits, but when Richard adds
his magic it probably will be. It is still an open issue where to put
what, and whether a new module would be fitting.
Richard surely will comment on this. I'd prefer the new instance
definitions in TypeLits to avoid orphans. Thanks for your input
though, this is exactly the kind of feedback we were hoping for :-)

Cheers,

    Gabor


[looks like I lost a previous version of this response, sorry if you
get it twice]

On 2/7/13, José Pedro Magalhães <jpm@cs.uu.nl> wrote:
> Hey Gabor,
>
> And why should it be part of base? Don't get me wrong, I'm not saying this
> is not important/useful. I'm just wondering about the reason to have it in
> base.
> Is it tied to TypeLits?
>
>
> Cheers,
> Pedro
>
> On Thu, Feb 7, 2013 at 2:21 PM, Gabor Greif <ggreif@gmail.com> wrote:
>
>> Oi José,
>>
>> this is a library-only issue, the branch is in libraries/base, thus
>> somewhat tied to the 7.8 release.
>>
>> Cheers,
>>
>>     Gabor
>>
>> On 2/7/13, José Pedro Magalhães <jpm@cs.uu.nl> wrote:
>> > On Wed, Feb 6, 2013 at 7:17 PM, Gabor Greif <ggreif@gmail.com> wrote:
>> >
>> >> On 2/6/13, Richard Eisenberg <eir@cis.upenn.edu> wrote:
>> >> > The only thing that stops me from saying "push" is that I think
>> >> > there
>> >> > is
>> >> a
>> >> > better organization for all of this. The ideas we're discussing here
>> >> (things
>> >> > like the Void type) don't seem to belong in TypeLits -- it has
>> >> > nothing
>> >> to do
>> >> > with literals. Time for a GHC.TypeReasoning module? Does someone
>> >> > have
>> a
>> >> > better name?
>> >>
>> >> Sounds okay. We can wiggle around on the new branch 'till we feel
>> >> comfortable, but I'd like to land this on master before the v7.8 train
>> >> leaves the station (i.e. the release branch is created).
>> >>
>> >
>> > Can you perhaps summarise exactly what needs to be added to GHC for
>> > this
>> to
>> > work?
>> > It's not immediately clear to me why this is not just a library issue.
>> >
>> >
>> > Thanks,
>> > Pedro
>> >
>>
>

_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs