[m-dev.] io__write and arrays

[David Glen JEFFERY]

Peter Schachte wrote:
> 
> > The downside is that a declaration would be required for each type that you
> > want to be able to print. Perhaps a mechanism which says `Everything is
> > in this class. Here's the default definition which can be overriden'
> > would be nice. (?)
> 
> Why not go a step further:  any type class which has defaults for all
> (what are they called?) type class parametric predicates/functions
> automatically applies to all types?  Can you think of a case where you
> define defaults for all <mouthfull> when you don't want that type class to
> apply to all types?

Class methods is probably the term you are looking for.

Anyhow, interesting thought. Perhaps a more general way of putting it would be:
If all class methods have default definitions and a type satisfies all the
constraints in the class's context, then a type may be considered to be a member
of the class.

Actually, I just thought of a way to achieve this, _if_ we allow overlapping
instance declarations. It goes a little bit like this...

class Printable a where
    display = ...
    .
    .
    .

instance Printable a

The `instance' declaration says that anything is printable (and uses the
defaults). A more specific declaration would override the defaults.

I'm still not convinced about overlapping instances, though.

> Hmmmm.  Just thought of a bit of a problem here, though.  What happens if
> the user declares a C type and doesn't provide a write, display or print? 
> Does display then report a runtime type error when someone tries to
> display one?  

At the moment, it would just print out the pointer that Mercury is hanging on
to. This is because c_pointer is (abstractly) defined as

    :- type c_pointer == int.

in mercury_builtin.m.

> You'd really like to create a type class displayable that
> automatically includes all atomic Mercury terms plus Mercury terms 
> composed of only displayable Mercury terms, plus any non-mercury terms
> that have a display operation (method, really).  Can you do that with type
> classes?

Hmmm. Maybe. It would require much greater (inbuilt) support for C types,
though.


love and cuddles,
dgj
-- 



This .sig deliberately left blank