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

[Ralph Becket]

Michael Day, Wednesday, 19 June 2002:
> 
> > 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?

This wouldn't be a problem for the C back-end, if one were to restrict
update operations to unique strings.  However, the IL back-end does not,
I believe, support mutable strings; instead one is expected to use the
StringBuilder class, from which one can obtain ordinary strings.

On that basis, it's probably better to have two separate ADTs.

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