[m-rev.] for review: mercury implementation of string.m

[Michael Day]

> It occurs to me that one is unlikely to want to build collections of
> such things or to use them as keys.  So I reckon that a "string builder"
> ADT for which equivalence was not based on the string being represented,
> but rather just using standard structural equivalence, would be fine.

Is it necessary to have two types, one for building strings and one for
deconstructing strings, or is there a good representation that will make
both efficient?

Michael

--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------