[m-dev.] io__write and arrays

[Fergus Henderson]

Peter Schachte, you wrote:
> 
> > `display' and `write' for user-defined Mercury types should be handled
> > automatically, using arg & functor and the predicates exported from
> > library/ops.m.  For user-defined types that are actually defined using
> > C code, then in the long term we should probably also do this with type
> > classes, but in the short term, we should at least handle the types
> > defined in the standard Mercury library, in particular arrays.
> 
> This is actually a little bit tricky (even with type classes).  If you're
> always meant to be able to read back in the output of display, how do you
> display a C-implemented type?

If you want to be able to read things back in again, then you need to
write out the type name (to disambiguate).  So to read them in again,
you can read in the type name, look up the type name in a global table
mapping from type name to base_type_info.

(base_type_info should perhaps be renamed type_ctor_info.)

> On a related topic, how should users write
> manifest constants of a C-implemented type?

I think they should write them as function calls to functions
that create values of that type.

> I suppose for now we can say you can't, but in the long run these are both
> very desirable.  One possible solution would be to have a general
> metasyntax for C-implemented types.  For the purposes of discussion let's
> use the syntax #Typename{...}, where "Typename" could be any type name,
> and the interpretation of the "..." depends on the type.  For example, an
> integer array of 1, 2, and 3 might be written #array{1,2,3}.  This is
> ugly, but it'll do for discussion. 

I think that

	uniq_array.from_list([1,2,3]) : uniq_array.uniq_array(int)

is less ugly.  Here `.' is for module qualifiers, `:' is for type qualifiers,
and `uniq_array.from_list' is a function that would be defined in
`library/uniq_array.m'.  You might not need all of those qualifiers.

(A syntax in which the type qualifier preceded the data rather than
following it might be slightly easier to work with, but it shouldn't
make much difference.)

Note that it should be the responsibility of the parser for uniq_array
to call the parsers for any subterms; it does not necessarily need to
call the list(T) parser and the uniq_array.from_list function, instead
the array could be constructed directly.  The string
"uniq_array.from_list([1,2,3]) : uniq_array.uniq_array(int)"
is a declarative specification, not an operational one; it denotes an
array, but that array need not actually be obtained by calling
the `from_list' function.

(Oh, yes, and `uniq_array' should be renamed `array'.)

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.