There was already the following statement in the SRFI text:
=======================================
Note: If an array does not have a setter, then we call it immutable even
though the array's getter might not be a "pure" function, i.e., the
value it returns may not depend solely on the arguments passed to the
getter.
=======================================
Brad

On 1/3/20 4:27 PM, John Cowan wrote:
> 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
> <mailto: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
>     <mailto: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).
>