[m-rev.] for post-commit review: fix string.from_char_list in C# and Java grades

[Paul Bone]

On Fri, Jul 04, 2014 at 01:36:33PM +1000, Julien Fischer wrote:
> On Fri, Jul 4, 2014 at 11:52 AM, Peter Wang <novalazy at gmail.com> wrote:
> 
> > If users of the non-C backends really want to use embedded null characters
> > > we can provide that facility some other way (on the understanding that
> > > programs that use such a facility won't work with the C backends).
> >
> > I've been thinking about a "binary string" type for arbitrary 8-bit
> > sequences, mainly for non-Unicode strings, or potentially non-Unicode
> > strings.  They might differ from a general byte array type in being
> > immutable and having string-like operations defined on them.  OTOH
> > it would be better not to introduce many similar types.
> 
> 
> I've not wanted such a thing myself, but if you think it would be
> sufficiently useful ...
> 
> We also need a float array type where the elements of the array are always
> unboxed,
> the performance of the normal arrays containing floats (doubles) on 32-bit
> machines
> being particularly bad for some programs (e.g. the nbody benchmark).
> 

Some time ago we talked about introducing kinds to Mercury.  And storing in
them the optional width of a type.  For example list(T) would always have
kind *, but this allows us to create multiple array(T)-like types, with
kinds such as *(8bit) *(32bit) *(64bit).  At least that was how I
interpreted the discussion.



-- 
Paul Bone