| I'm disturbed by the idea of adding explicit type application
| and the like to Haskell. Haskell language extensions are
| rapidly becoming a riotous array of confusing syntax and
| twisty semantic corners. From an experimenter's standpoint,
| this isn't so bad. However, many of these ext
| > Another possiblity would be to make the ConCls class look like this
| > class ConCls c where
| > name :: String
| > arity :: Int
| > ...etc...
| >
| > Now we'd have to give an explicit type argument at the call site:
| >
| > show {| Constr c t |} (Con x) = (name
| As long as we're reifying everything in sight, why not
| simplify the design problem and reify the constructor dictionaries?
Because the generic function may be building the contructor
not taking it apart. (Think of a generic read function). So there
is no reified constructor to deconstruct.
* Language philosophers who are skimming this discussion will want to
take a look at below.
Simon PJ writes:
> One thing that is slowing me down is a design uncertainty: how to
> deal cleanly with constructors. To write read, show, etc, one needs
> access to the constructor name, fixity
On Wed, Feb 20, 2002 at 01:15:36PM -0800, Simon Peyton-Jones wrote:
> Another possiblity would be to make the ConCls class look like this
> class ConCls c where
> name :: String
> arity :: Int
> ...etc...
>
> Now we'd have to give an explicit type argument at the ca
| and I know from testing earlier versions that the
| generic-classes support was pretty buggy. Is there any hope
| of a revival? Does it already work in CVS? I suspect it will
| rot away if nobody works on it.
|
| Any comments from the implementors - does the idea "fit well"
| with ghc? Is i
