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

[Ralph Becket]

Peter Ross, Tuesday, 18 June 2002:
> rafe wrote:
> 
> > 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.
> >
> This is true.  I came across the same problem when looking at writing a
> typeclass based stream library for I/O, you really don't want to use the
> string primitives for doing I/O.  You just want some abstract type that
> you can get the resulting string out of when finished.  I also did a
> similar thing for string__format where I tried to minimise the number of
> strings that were allocated to try and improve its performance.

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.

> The reference manual states that strings are represented by the typedef
> MR_String, and this is equivalent to char *.  A clever string
> representation would be required to enforce this at the c code boundary,
> and I think it would break too much code to change this constraint.
> Strings are just too fundamental a data type not to be used heavily.
> However if a representation could be found that is cheap to marshall
> across this boundary then I would be all for it.

Well, one could have

	typedef struct { unsigned int length; char chars[1] } MR_String

and if you wanted to make these things look like char * from the C side,
just pass pointers to the chars field rather than the struct as a whole.
Alas, this violates the no-pointers-into-structs constraint and the C
code has no way of knowing the proper length of a string that contains
NULs.

Oh well,

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