Re: Analysis of property visibility, immutability, and cloning proposals

On 2 January 2021 21:25:08 GMT+00:00, Larry Garfield <larry@garfieldtech.com> wrote: >If a stream is not seekable, then it would have to consume and destroy >$fp in the process (unset it). So: > >[$line1, $fp2] = read_line($fp); >[$line2, $fp2] = read_line($fp); > >The second line would throw an error that $fp "has been consumed" or >something like that. But even that still creates potential for >spooky-action-at-a-distance if $fp was passed into a function, gets >read in that function, and then the parent call scope has a broken $fp >lying around. Yes, that is where "uniqueness attributes" come in: in Clean, that's basically how I/O looks, but either of those scenarios would produce an error *at compile time*. The type system includes the constraint that the file handle must not be reachable from anywhere else when passed to the read_line function, whether that's use of the same variable after the call, assignment to an extra variable, capture by some other function, or storage in an array or record. The same constraint can be added to custom functions, allowing the compiler to reuse the memory for, say, a large array that you're adding an item to. So you still write the code as though it was immutable, and can reason about it that way, but can also prove that it's safe to actually mutate it in place. Similar things can be done, in a slightly different way, with Rust's ownership/lifetime system: the "borrow checker" proves that the manipulations you're doing are free of "action at a distance" by prohibiting anything that would create ambiguous "ownership". Regards, -- Rowan Tommins [IMSoP]