[m-dev.] io__read

[Fergus Henderson]

Tyson Richard DOWD, you wrote:
> 
> What happens when you want to io__read a list of univ?
> 
> Usually the type of the thing we want to read tells us how to parse it.
> The type_info for list of univ can't tell us what the type of each
> element is, so we cannot parse them. The data itself cannot tell us
> what the type of each element is.

Well, the data could tell you what the type of each element is.  You
could have io__write for a univ write out the type name as well as the
value.  You would need a global hash table mapping type names to
base_type_infos so that you could construct a type_info for the named
type.

> This is a bit of a problem, because although io__write can write a 
> list of univ, io__read cannot read one.

`univ' is not the only type with problems here -- so is float,
since string__to_float et al don't handle IEEE NaN and Infinity.

> (The only solution we've seen so far is a co-routining read, that
> suspends until it knows what the actual type of a univ is - it will come
> from a call to univ_to_type at some stage, then parses it. But 
> implementation of this is rather tricky - univ_to_type will perform
> unification on the type_infos rather than compare on the type_infos, and
> wake-ups and things will have to happen. Ick).

That's not correct anyway: there's no guarantee that the first call to
univ_to_type was intended to succeed.  Reordering calls to univ_to_type
on the same univ with different types might change the program's
results.

> For the moment, I don't think univs will be able to be read.

I think that is OK, at least for the moment.
Just make sure you document it.

-- 
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.