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

[Julien Fischer]

On Fri, Jul 4, 2014 at 11:52 AM, Peter Wang <novalazy at gmail.com> wrote:

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

I think we just have to adopt the lowest common denominator approach here,
especially if the backend with the limitation is one of the C backends.
The property of being able retarget a program to the JVM / .NET  / native
executable with just
a recompile is a useful one and I'd like to maintain that as much as
possible.

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

Cheers,
Julien.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20140704/2d32b2a2/attachment.html>