Wish list: expanded defaulting, dependent types, reflection

[Mike Gunter]

I would like define arithmetic operations with heterogenous types.
(I'm interested in sized types for an embedded hardware description
language.)  One approach would be to use multiple-parameter type
classes; e.g:

  class Add a b c where add :: a -> b -> c  

There does not seem to be a way to do everything I'd like in GHC even
in its most permissive mode (I'm using "-fallow-overlapping-instances
-fallow-undecidable-instances".)  In particular, I'd like to use bare
integer literals together with values of the types I define.  The more
straightforward approach, using the standard fromInteger definition,
runs up against the limitation of default mechanism to standard
classes.  What's the purpose of this limitation?  Any chance GHC could
optionally relax it?  (Absent an implementation it's hard to be sure
this is sufficient for my purposes.)

Another scheme is to give GHC the -fno-implicit-prelude option and
redefine fromInteger to return a type, say, ConstInteger, for which
all of the operations have an instance.  This seems to work for
operations I am defining but makes it impossible to use bare literals
as arguments to functions defined elsewhere (which are expecting an
Int/Integer/Double/...)

I think (I have no experience here!) I'd be happiest if GHC
implemented dependent types.  That would seem to solve this problem
and others.  Even if this broke most Haskell 98 code, I think I'd
turn on the -fdependent-types option.


A completely different approach would be to use the standard Haskell
numeric classes (with homogeneous types) with the size-constraint
system implemented in my Haskell code.  This approach would be more
attractive if my Haskell implementation provided a small amount of
reflective capability.  In particular, I would want to generate error
messages with the source file, line number, and function.  GHC does a
very good job of reporting this information for type errors.  Could it
be made available to the program being compiled?  (I could also use
such a mechanism to make it possible to give sensible names to
entities (wires, gate instances) in the output generated from the
HDL.)


So, my wish list is

  (1) dependent types, or
  (2) remove the restriction that default only works on standard
      classes and
  (3) a small amount of reflection (file,line number,function name) or
  (4) (best) a way to do what I need without (1)-(3).

Thanks.

        mike