Thanks for the clarification. Perhaps "immutable" should be changed to "read-only" in the new draft to avoid misleading people.

On Fri, Jan 3, 2020 at 1:56 PM Bradley Lucier <xxxxxx@purdue.edu> wrote:
You are correct, “immutable” arrays are ones that don’t have a mutator in the interface (i.e., it is an error to call (array-setter A)).  There is no guarantee that (array-getter A) is a “pure” function.

Brad

> On Jan 3, 2020, at 1:51 PM, John Cowan <xxxxxx@ccil.org> wrote:
>
> I'm writing a non-mathematician's guide to SRFI 122 (partly for my own benefit), and I'm not clear how immutable arrays are supposed to work.  Is it an error if the getter function is not pure and functional (i.e. depends on something other than the indices passed)? 
>
> For example, suppose you have an array that fetches its elements lazily from a file.  If another process mutates the file, presumably future element references will get the new values, so that the array is read-only rather than truly immutable.  Is that all right, or is actual immutability assumed, such that if you break it, you violate some invariant?
>
> BTW, I am working from <http://github.com/gambiteer/srfi-122/srfi-122.html rather than the published SRFI.  One may conveniently read this version online at <https://htmlpreview.github.io/?https://raw.githubusercontent.com/gambiteer/srfi-122/master/srfi-122.html>.  I look forward to this version becoming a new SRFI before the Orange Edition ballot, which will be sometime this year (but not soon, I have a lot of SRFIs to write and implement).