fjh at cs.mu.oz.au
Mon Feb 24 11:39:34 AEDT 1997
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
> 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
> 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 220.127.116.11 | -- the last words of T. S. Garp.
More information about the developers