<div dir="ltr">I'll add the flag to BoundsCheckByte and see if it makes things simpler. I can take care of the other changes if so. This will be on the strcat branch.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 March 2017 at 18:49, Magnus Myreen <span dir="ltr"><<a href="mailto:magnus.myreen@gmail.com" target="_blank">magnus.myreen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 23 March 2017 at 09:45, Ramana Kumar <<a href="mailto:Ramana.Kumar@cl.cam.ac.uk">Ramana.Kumar@cl.cam.ac.uk</a>> wrote:<br>
> The SML semantics for when to raise exceptions is a little weird:<br>
><br>
> "If di < 0 or if |dst| < di+|src|, then the Subscript exception is raised."<br>
><br>
> This means if I want to copy an empty array into (non-existent) index 3 of a<br>
> length 3 array, there should be no exception.<br>
> This is hard to accomplish with our BoundsCheckByte semantics which ensures<br>
> a strict less-than the length.<br>
><br>
> How bad is it to use an explicit LessEq with LengthByte, rather than<br>
> BoundsCheckByte?<br>
> Or alternatively, can we add that flag to BoundsCheckByte to change its<br>
> comparison to less-or-equal?<br>
<br>
</span>Adding this flag should be easy. I'm happy to update data_to_word for<br>
this if someone else takes care of the other changes for the new flag.<br>
<div class="HOEnZb"><div class="h5"><br>
> Or do we want to not follow the SML semantics?<br>
><br>
> On 21 March 2017 at 11:01, Ramana Kumar <<a href="mailto:Ramana.Kumar@cl.cam.ac.uk">Ramana.Kumar@cl.cam.ac.uk</a>> wrote:<br>
>><br>
>> We don't have any higher-order primitives currently... I imagine they'd be<br>
>> quite a bit harder to verify and implement efficiently... You would want<br>
>> clos_call/known type optimisations to specialise a primitive like unfold.<br>
>><br>
>> I think I'm currently leaning towards reinstating the concat primitives<br>
>> alongside the Copy{Str,Aw8}{Str,Aw8} primitives. The concat ones eventually<br>
>> get implemented in terms of the latter, but only once it's possible to do so<br>
>> without the extra copying.<br>
>><br>
>> On 21 March 2017 at 09:53, <<a href="mailto:Michael.Norrish@data61.csiro.au">Michael.Norrish@data61.csiro.<wbr>au</a>> wrote:<br>
>>><br>
>>> Rather than having to initialise an empty string and then copy into it,<br>
>>> why not provide something like a tabulate or unfold function that generates<br>
>>> the string? The function passed in would then be able to write directly<br>
>>> into the string’s memory. I’m not sure how to set it up to write whole<br>
>>> strings at a time (the helper function would have to return strings, which<br>
>>> would almost certainly require a new allocation), but if done a character at<br>
>>> a time, the char values might get to stay in registers:<br>
>>><br>
>>><br>
>>><br>
>>> String.tabulate : int * (int -> char) -> string<br>
>>><br>
>>><br>
>>><br>
>>> If you had substrings (implemented as string * offset * length triples<br>
>>> and sharing the underlying string), then something like<br>
>>><br>
>>><br>
>>><br>
>>> String.unfold : ‘a * (‘a -> (substring * ‘a) option) * int -> string<br>
>>><br>
>>><br>
>>><br>
>>> could be done, where the ‘a is a generic “state” parameter (the list of<br>
>>> strings to concat), and where the int is maximum length of the result.<br>
>>><br>
>>><br>
>>><br>
>>> I think String.concat could be implemented with the latter without any<br>
>>> redundant copying.<br>
>>><br>
>>><br>
>>><br>
>>> Michael<br>
>>><br>
>>><br>
>>><br>
>>> From: Ramana Kumar <<a href="mailto:Ramana.Kumar@cl.cam.ac.uk">Ramana.Kumar@cl.cam.ac.uk</a>><br>
>>> Date: Monday, 20 March 2017 at 16:29<br>
>>> To: "<a href="mailto:developers@cakeml.org">developers@cakeml.org</a>" <<a href="mailto:developers@cakeml.org">developers@cakeml.org</a>><br>
>>> Subject: Re: [CakeML-dev] New string/bytearray operations<br>
>>><br>
>>><br>
>>><br>
>>> I've been rethinking these primitives after the discussion at the last<br>
>>> hangout, and have come up with a different set altogether. Can you see a<br>
>>> simpler or more elegant approach to the one described below?<br>
>>><br>
>>> Here is the new approach I am considering:<br>
>>><br>
>>> 4 copying primitives in the source language going from string/bytearray<br>
>>> to string/bytearray.<br>
>>><br>
>>> The source comes with an offset and a length to copy.<br>
>>><br>
>>> If the destination is a string, a new string is created. If the<br>
>>> destination is a bytearray, it must be provided.<br>
>>><br>
>>> Concatenation (of lists of strings/arrays) and conversions between<br>
>>> (whole) strings and (whole) bytearrays can be implemented in the basis<br>
>>> library in terms of these primitives. And the primitives should be<br>
>>> efficiently implementable in terms of a byte-based memcpy primitive further<br>
>>> down. (There will need to be bounds checking in the source-level semantics<br>
>>> (i.e., Subscript exception can be raised), and this will sometimes be<br>
>>> unfortunate (i.e., when obviously in bounds), but I don't think this is too<br>
>>> costly.)<br>
>>><br>
>>><br>
>>><br>
>>> On 14 March 2017 at 16:52, Ramana Kumar <<a href="mailto:Ramana.Kumar@cl.cam.ac.uk">Ramana.Kumar@cl.cam.ac.uk</a>><br>
>>> wrote:<br>
>>><br>
>>> Hi all,<br>
>>><br>
>>> I've started adding string/bytearray conversion and concatenation<br>
>>> primitives (issues 244 and 245). Before getting too deep into updating<br>
>>> the compiler etc., may I request a review of the semantics? Here they<br>
>>> are:<br>
>>><br>
>>><br>
>>> <a href="https://github.com/CakeML/cakeml/commit/67dd15bbd03f516be618ba72f1d56a2764209263" rel="noreferrer" target="_blank">https://github.com/CakeML/<wbr>cakeml/commit/<wbr>67dd15bbd03f516be618ba72f1d56a<wbr>2764209263</a><br>
>>><br>
>>> I noticed that v_to_char_list might be better as vs_to_char_list, to<br>
>>> be run after v_to_list (rather than duplicating its<br>
>>> list-deconstruction functionality). But I leave such refactoring for<br>
>>> another time.<br>
>>><br>
>>> Cheers,<br>
>>> Ramana<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> Developers mailing list<br>
>>> <a href="mailto:Developers@cakeml.org">Developers@cakeml.org</a><br>
>>> <a href="https://lists.cakeml.org/listinfo/developers" rel="noreferrer" target="_blank">https://lists.cakeml.org/<wbr>listinfo/developers</a><br>
>>><br>
>><br>
><br>
</div></div></blockquote></div><br></div>