<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 4, 2014 at 11:52 AM, Peter Wang <span dir="ltr"><<a href="mailto:novalazy@gmail.com" target="_blank">novalazy@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, 4 Jul 2014 10:11:43 +1000, Julien Fischer <<a href="mailto:jfischer@opturion.com">jfischer@opturion.com</a>> wrote:<br>

> On Fri, Jul 4, 2014 at 10:02 AM, Peter Wang <<a href="mailto:novalazy@gmail.com">novalazy@gmail.com</a>> wrote:<br>
><br>
> > On Thu, 3 Jul 2014 17:47:21 +1000 (EST), Julien Fischer <<br>
> > <a href="mailto:jfischer@opturion.com">jfischer@opturion.com</a>> wrote:<br>
> > ><br>
> > > For post-commit review by anyone.<br>
> > ><br>
> > > Branches: 14.01, master<br>
> > ><br>
> > > -------------------------------------<br>
> > ><br>
> > > Fix the behaviour of string.from_char_list in C# and Java grades.<br>
> > ><br>
> > > The predicate string.from_char_list and string.from_reverse_char_list<br>
> > should<br>
> > > throw an exception if their input lists contain the null character.  This<br>
> > > was not done for the C# and Java grades for the former, and the C# grade<br>
> > for<br>
> > > the latter.<br>
> > > (This fixes the failure of tests/hard_coded/null_char in the C# grade and<br>
> > > almost fixes it for the Java grade.)<br>
> > ><br>
> > > library/string.m:<br>
> > >       Make the above predicates throw an exception if their input lists<br>
> > >       contain the null character.<br>
> > ><br>
> > > NEWS:<br>
> > >       Announce the above fix.<br>
> ><br>
> > I think embedded null characters should be allowed when the underlying<br>
> > string representation allows it, so this was more a bug in the<br>
> > documentation.  Obviously, from_char_list and from_reverse_char_list<br>
> > should have consistent behaviour within the same grade.<br>
> ><br>
><br>
> I disagree.  I think the standard library predicates should be consistent<br>
> in their behaviour across all grades and all backends.  (I realise this is<br>
> more an ideal, rather than something that is completely achievable in<br>
> reality.)  If nothing else, having variations in behaviour makes the whole<br>
> thing more difficult to test.<br>
<br>
</div></div>That's true.  However, when the behaviour is due to a limitation in one<br>
backend then it's questionable that it should carry over to other<br>
backends.  I don't particularly mind in this case, though.<br></blockquote><div><br></div><div>I think we just have to adopt the lowest common denominator approach here,</div><div>especially if the backend with the limitation is one of the C backends.</div>
<div>The property of being able retarget a program to the JVM / .NET  / native executable with just</div><div>a recompile is a useful one and I'd like to maintain that as much as possible.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
> If users of the non-C backends really want to use embedded null characters<br>
> we can provide that facility some other way (on the understanding that<br>
> programs that use such a facility won't work with the C backends).<br>
<br>
</div>I've been thinking about a "binary string" type for arbitrary 8-bit<br>
sequences, mainly for non-Unicode strings, or potentially non-Unicode<br>
strings.  They might differ from a general byte array type in being<br>
immutable and having string-like operations defined on them.  OTOH<br>
it would be better not to introduce many similar types.</blockquote><div><br></div><div>I've not wanted such a thing myself, but if you think it would be sufficiently useful ...</div><div><br></div><div>We also need a float array type where the elements of the array are always unboxed,</div>
<div>the performance of the normal arrays containing floats (doubles) on 32-bit machines</div><div>being particularly bad for some programs (e.g. the nbody benchmark).</div><div><br></div><div>Cheers,</div><div>Julien. </div>
<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div></div><br></div></div>