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

[Peter Wang]

On Fri, 4 Jul 2014 10:11:43 +1000, Julien Fischer <jfischer at opturion.com> wrote:
> On Fri, Jul 4, 2014 at 10:02 AM, Peter Wang <novalazy at gmail.com> wrote:
> 
> > On Thu, 3 Jul 2014 17:47:21 +1000 (EST), Julien Fischer <
> > jfischer at opturion.com> wrote:
> > >
> > > For post-commit review by anyone.
> > >
> > > Branches: 14.01, master
> > >
> > > -------------------------------------
> > >
> > > Fix the behaviour of string.from_char_list in C# and Java grades.
> > >
> > > The predicate string.from_char_list and string.from_reverse_char_list
> > should
> > > throw an exception if their input lists contain the null character.  This
> > > was not done for the C# and Java grades for the former, and the C# grade
> > for
> > > the latter.
> > > (This fixes the failure of tests/hard_coded/null_char in the C# grade and
> > > almost fixes it for the Java grade.)
> > >
> > > library/string.m:
> > >       Make the above predicates throw an exception if their input lists
> > >       contain the null character.
> > >
> > > NEWS:
> > >       Announce the above fix.
> >
> > I think embedded null characters should be allowed when the underlying
> > string representation allows it, so this was more a bug in the
> > documentation.  Obviously, from_char_list and from_reverse_char_list
> > should have consistent behaviour within the same grade.
> >
> 
> I disagree.  I think the standard library predicates should be consistent
> in their behaviour across all grades and all backends.  (I realise this is
> more an ideal, rather than something that is completely achievable in
> reality.)  If nothing else, having variations in behaviour makes the whole
> thing more difficult to test.

That's true.  However, when the behaviour is due to a limitation in one
backend then it's questionable that it should carry over to other
backends.  I don't particularly mind in this case, though.

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

Peter