[m-rev.] diff: implement concat_string_list for .NET

[Michael Day]

> There is a representation issue in that it would be nice to allow
> every char to appear in a string, rather than excluding NULs.

Given that there is no way to create such a string in Mercury (right?) and
no way to receive such a string from the C interface (if it's truly
returning a string rather than an arbitrary buffer) this doesn't seem
entirely convincing. Perhaps a good char array type in Mercury would
reduce the pressure on string? (Or eliminate the need for string? :)

> There are certainly efficiency issues.  The code in string.m calls
> string.length all over the place.  Worse, in many cases the Mercury
> compiler may not be able to optimize away redundant calls thanks to the
> use of foreign code and the C compiler often doesn't have enough
> information, either.

In that case, I suppose a relatively straightforward test would be to
change the representation of string and benchmark the compiler. Come to
think of it, what kind of string representations do Java and C# have? Has 
the world settled on C strings or are there still pockets of resistance?

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