Donald Bruce Stewart
dons at cse.unsw.edu.au
Mon Aug 7 05:51:45 EDT 2006
While we're thinking about defaulting, I have a question..
ghci uses an extended defaulting system, to allow things like:
Prelude> reverse 
to work, and to have the right instance of Show found. The manual says:
"..it is tiresome for the user to have to specify the type, so GHCi extends
Haskell's type-defaulting rules (Section 4.3.4 of the Haskell 98 Report
(Revised)) as follows. If the expression yields a set of type constraints
that are all from standard classes (Num, Eq etc.), and at least one is
either a numeric class or the Show, Eq, or Ord class, GHCi will try to use
one of the default types, just as described in the Report. The standard
defaulting rules require that one of the classes is numeric; the difference
here is that defaulting is also triggered at least one is Show, Eq, or Ord."
Currently, there is no way to get at this "extended" defaulting for compiled
modules. However, I have a use case for in fact doing this.
With runtime evaluated Haskell, embedding 'interpreters' (over hs-plugins) is
easy. lambdabot, for example, implements a sandboxed haskell eval system. But
it doesn't have access to the defaulting mechanism of ghci, so we have:
dons:: > reverse 
lambdabot:: Add a type signature
dons:: > reverse  :: [()]
Which is annoying -- newbies wonder why they have to add these extra
constraints to get a Show instance.
I'm wondering, since the extended defaulting mechanisms are already implemented,
could they be made available to compiled modules as well, perhaps using a flag,
-fextended-defaulting? Are there any technical reasons not to do this?
More information about the Cvs-ghc