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

[Ralph Becket]

Michael Day, Monday, 17 February 2003:
> 
> > > Urk - while in principle I would support this, it would require
> > > changing a lot of interface code and should not be undertaken
> > > lightly :)
> > 
> > Hmm, shame.  Oh well.
> 
> Perhaps a gentle starting point could be to make a "cstring" module
> and foreign_type that could be used for interfacing with C libraries,
> but again it could lead to a fair deal of hassle if code has to
> convert back and forth between string and cstring, and a fair bit of
> duplication if it doesn't.
> 
> Are there any studies comparing the efficiency of the two string
> approaches? Presumably this would have been a hot issue back in the
> Pascal vs C days?

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

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.

The C string representation is essentially char[] - and mutable at that
- which is where many problems arise.  C programs using arrays are
always a little problematic: either the programmer has to explicitly
keep track of the array length, or use fixed sized arrays, or use some
sentinel value (e.g. NUL).  It's all a bit of a hack.

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