Tutorial on Mutability and Imperative Programming

[cuihtlauac]

Mutable Data: references, records and arrays/bytes
Imperative
Exceptions
Howto mix styles without getting into trouble
Refunctionalization techniques

[Tchou]

Hi,
some low-level remarks.

# #show ref;;

why not #show_type ref ? This would only show the type definition (which is what is interesting) and would allow you to remove the awkward reference to binding with C (also I haven't checked but I think makemutable is not a C function but a compiler primitive).

"Note: This example will not run in the REPL, since the function Array.truncate is not defined."

Why not use Array.sub then ? it only adds a 0 parameter and the code can actually be tested (and replace the paragraph about the fake truncate by on explaining in passing what Array.sub does).

Not too sure about the "Analytics" example. I would avoid depending on code that is left to the reader to imagine. I think you could achieve the same effect by logging something in a or on stderr. I would maybe start this part by a more general remark saying that in OCaml, side-effects do not occur in types (whether they are modification of mutable state or exceptions). That is a strength (allows you to use local side effects, or functions that behaves as-if they were pure but more efficient) but also a problem since, when the side effect is actually part of the spec, one has to rely on documentation to be aware of that (e.g. a function that mutates its argument).

As for side effects in arguments I would generalize a bit saying that this also apply to constructor argument and that code such as:

let r = ref 0 in
((incr r; !r), (incr r; !r))

may return different values depending on the back-end, optimization level, version of the compiler etc…

[cuihtlauac]

why not #show_type ref ? This would only show the type definition (which is what is interesting) and would allow you to remove the awkward reference to binding with C (also I haven't checked but I think makemutable is not a C function but a compiler primitive).

Fixed

"Note: This example will not run in the REPL, since the function Array.truncate is not defined."

If we show code which is bad but somehow working, it will be copied and used. truncate is way to work around that (analytics undefined too).

Not too sure about the "Analytics" example. I would avoid depending on code that is left to the reader to imagine. I think you could achieve the same effect by logging something in a or on stderr. I would maybe start this part by a more general remark saying that in OCaml, side-effects do not occur in types (whether they are modification of mutable state or exceptions). That is a strength (allows you to use local side effects, or functions that behaves as-if they were pure but more efficient) but also a problem since, when the side effect is actually part of the spec, one has to rely on documentation to be aware of that (e.g. a function that mutates its argument).

I like the idea you suggest about adding text. What I like about analytics is the discrepancy between copying an array and opening a network connection. But you are right, we should not assume everybody knows about analytics and provide some details

let r = ref 0 in
((incr r; !r), (incr r; !r))

Excellent example!

[christinerose]

Questions found in my review

[christinerose]

Please check my revision here to ensure it's still accurate. 🙂

[christinerose]

Since this doesn't return anything but just leaves a space for more input, should we mention that or clarify it's necessary to return twice to get back to the prompt?

[cuihtlauac]

I need to fix offline

[cuihtlauac]

We need to say something like:

Type and edit any single line text, and then press return to get back to the repl

[christinerose]

A few questions

[sabine]

Anything left to do before me merge this?