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

[Ralph Becket]

Michael Day, Monday, 17 June 2002:
> 
> Right. How about adding a general string buffer type, containing a string
> and an index into that string (is anything else required?) that can be
> used by lex and other modules that process strings in this way so that
> first_char can be deprecated/removed?

first_char was always a bad idea.  [unsafe_]index and fold[lr] are the
right tools for the job.

Constructing strings is a different matter.  If you use clever
representations, such as concatenation trees of substrings, you will
likely also have to have user-defined equality since there will be
multiple ways to represent each string.  This brings it's own set of
problems.  I'm inclined to the idea that a separate data structure is
appropriate for building strings.

I believe the reason for not having clever (immutable) string
representations is that the C interface is easier to work with if you
just use C strings, which couldn't be more basic (I've been bitten once
or twice by the fact that you can't have NULs in Mercury strings if
you're using a C back-end.)  I'm not 100% convinced this is the right
approach... Pete, Tyson?

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