[commit: base] master: Implement "TypeLevelReasoning" proposal at wiki:TypeLevelReasoning (365b9d8)
Simon Peyton-Jones
simonpj at microsoft.com
Thu Jul 25 05:06:34 CEST 2013
Hs-boot files tend to get in the way of optimisation. Moreover, sometimes they are truly necessary, and if there are un-necessary ones that can greatly complicate adding necessary ones. There are already LOTS of data types declared as instances of Typeable at the place that Typeable class is defined; no harm in one more.
So I'd really prefer the re-jig if that's ok
Simon
| -----Original Message-----
| From: Richard Eisenberg [mailto:eir at cis.upenn.edu]
| Sent: 24 July 2013 22:37
| To: Simon Peyton-Jones
| Cc: ghc-devs at haskell.org
| Subject: Re: [commit: base] master: Implement "TypeLevelReasoning" proposal
| at wiki:TypeLevelReasoning (365b9d8)
|
| I agree that hs-boot files are a little inelegant, but is there a bigger problem with
| them? I consider instances to be more tied to a datatype definition than the class
| definition. It may be possible (I think it is) to avoid the Proxy.hs-boot and
| Equality.hs-boot files if we scatter their instances across the modules. But, then
| the "definition" of these types would be spread across a large surface area. To me,
| that makes the types harder to update and perhaps harder to understand (though
| haddock does a nice job of collecting all the instance declarations together).
|
| So, my thought is that the mechanism of hs-boot files may be a little ugly, but it
| makes the code (that is, the collection of instances) easier to consider as a whole
| and easier to update. That tradeoff seems worthwhile.
|
| That all said, if you (or others) feel strongly about it, I can rejigger it.
|
| Richard
|
| On Jul 24, 2013, at 3:14 PM, Simon Peyton-Jones wrote:
|
| > Richard I am deeply suspicious of all these hs-boot files.
| >
| > Instances should preferably go EITHER with the data type declaration OR with
| the class declaration.
| >
| > In the case of Proxy, for example, why can't the Typeable instance for Proxy go
| in Data.Typeable.Internals? (And perhaps similarly for other instances.)
| >
| > Simon
| >
| > | -----Original Message-----
| > | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of
| > | Richard Eisenberg
| > | Sent: 24 July 2013 12:41
| > | To: ghc-commits at haskell.org
| > | Subject: [commit: base] master: Implement "TypeLevelReasoning" proposal
| at
| > | wiki:TypeLevelReasoning (365b9d8)
| > |
| > | Repository : http://darcs.haskell.org/ghc.git/
| > |
| > | On branch : master
| > |
| > |
| http://hackage.haskell.org/trac/ghc/changeset/365b9d86d195dc483610a68836b4
| > | 063656602244
| > |
| > | >---------------------------------------------------------------
| > |
| > | commit 365b9d86d195dc483610a68836b4063656602244
| > | Author: Richard Eisenberg <eir at cis.upenn.edu>
| > | Date: Wed Jul 24 12:38:50 2013 +0100
| > |
| > | Implement "TypeLevelReasoning" proposal at wiki:TypeLevelReasoning
| > |
| > | This commit includes a propositional equality (:=:) in Data.Type.Equality,
| > | a Proxy type in Data.Proxy, and has updates to Typeable.
| > |
| > | There is an unfortunate number of hs-boot files necessary, but that
| > | seems cleaner than moving Typeable instances around willy-nilly.
| > |
| > | Data/Data.hs | 2 +-
| > | Data/Proxy.hs | 129
| > | ++++++++++++++++++++++++++++++++++++++++
| > | Data/Proxy.hs-boot | 5 ++
| > | Data/Type/Equality.hs | 99
| > | ++++++++++++++++++++++++++++++
| > | Data/Type/Equality.hs-boot | 6 ++
| > | Data/Typeable.hs | 42 +++++++------
| > | Data/Typeable/Internal.hs | 5 +-
| > | Data/Typeable/Internal.hs-boot | 3 +-
| > | base.cabal | 2 +
| > | 9 files changed, 269 insertions(+), 24 deletions(-)
| > |
| > |
| > | Diff suppressed because of size. To see it, use:
| > |
| > | git show 365b9d86d195dc483610a68836b4063656602244
| > |
| > | _______________________________________________
| > | ghc-commits mailing list
| > | ghc-commits at haskell.org
| > | http://www.haskell.org/mailman/listinfo/ghc-commits
| >
| >
| >
|
More information about the ghc-devs
mailing list