Hi Hongbo, I just quickly checked with the try BuckleScript website with 
the following code:

let test = [| 0; 1; 2; 3; 4; 5 |];;

let _ =
  test.(-1) <- -1;
  Js.log test.(-1)

to get the answer -1, which indicates that it is indexing outside the 
bounds of the array to set a new value.

I notice that try BuckleScript is version 1.21, so that may make a 
difference, and as well it may be compiling with options that allow this to 
automatically use the unsafe version.

As I said, not a problem for my use, as a Elm back end not a problem as Elm 
doesn't use arrays directly, but it isn't strictly type safe.

On Tuesday, 24 January 2017 09:16:11 UTC+7, Bob Zhang wrote:
>
> We do bounds check, but we also provide unsafe version which does not do 
> bound check for performance reasons. If you find the safe function which 
> does not, you are welcome to file an issue 
> On Mon, Jan 23, 2017 at 8:41 PM GordonBGood <[email protected] 
> <javascript:>> wrote:
>
>> On Tuesday, 24 January 2017 01:26:49 UTC+7, OvermindDL1 wrote:
>>>
>>> Bucklescript de-curries as much as possible, however you can also force 
>>> it in the type system explicitly by adding the annotation type of `[@bs]` 
>>> to a function (type) definition, that enforces uncurrying at the type level 
>>> and will even propagate in usage as expected to make sure accidental 
>>> currying of it is not done (though you can still explicitly curry it by 
>>> wrapping it in a curried type).  In most cases it de-curries very well and 
>>> you never need to use `[@bs]` (the only real time I've used it is on DOM 
>>> callback registrations with more than one argument to make sure I do not 
>>> accidentally pass a curried version to one, never used it in 'user' code as 
>>> of yet).
>>>
>>
>> Yes, I've used the {@bs} notation, usually on very low-level code to 
>> force no currying (or passing of any arguments); as you say BuckleScript is 
>> very good of determining an appropriate use of currying.  If one were to 
>> use an Elm front end to OCaml/BuckleScript, it would be nice to add the 
>> ability to inject these macro-type annotations into the code, probably as a 
>> specially formed comment, so that in effect we could write all the Native 
>> code modules in the high level environment, which works very well in 
>> BuckleScript.
>>
>> One thing that BuckleScript does by default that breaks type safety is 
>> not do array bounds checks, but that wouldn't be a problem for an Elm front 
>> end as Elm does not use (mutable) arrays directly.
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Elm Discuss" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/elm-discuss/Um7WIBTq9xU/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to