Hi Eliot,

I have not given this much thought, but just to get the discussion going
I'll answer from the POV of maintaining a package like OSProcess. As the
maintainer, I would be happier to just fix my code and be done with it,
as opposed to trying to answer questions from various people who might
or might not have have yet another obscure preference set.

But the counter argument is that not all of the useful external packages
have active maintainers, and we don't want to set up a situation where
those packages cannot be used. I don't know if that would be the case
here, but if so we would be well advised to provide a preference to keep
those packages useable.

If we do add a preference, then I would rather that the default be to
simply raise an error (your preferred state of affairs), and the preference
would exist only in the interest of allowing existing (unmaintained?)
packages to be loaded and run.

Off topic for your question, but just for my own understanding - why is
it good for a ByteArray to be read-only? I would have thought that it
would be just an array of things that happen to be very small positive
integers (sorry I am sure this has been discussed before).

Dave


On Sun, Mar 25, 2018 at 04:18:32PM -0700, Eliot Miranda wrote:
> Hi All,
> 
>     the VM now has support for read only objects, and the first logical
> application is for literals, making boxed floats, strings, symbols, arrays
> and byte arrays read-only.  Doing so is trivial; only two methods need to
> be modified (see attached).  AFAIA little or no core code is broken by
> making literals read-only.  However, when I ran the test suite with
> read-only literals in place, several tests were broken.  These are things
> like creating null-terminated strings for testing OSProcess, by replacing
> spaces in string literals with zeros, etc.
> 
> When we added read-only literals to VisualWorks in something like vw7.0 the
> balance of opinion was that we should not break user code.  Hence we
> implemented a preference scheme with three states:
> 
> - By default, an attempt to modify a read-only literal would silently make
> the literal mutable temporarily,update it and then reenable read-onlyness.
> - A second state would issue a warning to the transcript, while doing what
> the default did.
> - The third state would raise an error
> 
> Remember that all one needs to do to fix code that modifies literals is to
> send copy to the literal before modifying the copy, since copies of
> read-only literals are mutable.
> 
> I was on the side of only raising an error, but was overruled :-).  I
> wonder what this community thinks.  If there are strong views that user
> code should continue to function unchanged (even though it is modifying
> literals, which is so so wrong :-) ) I'm happy to implement a scheme
> similar to that for VisualWorks.  But I'd rather not have to and simply
> have people fix their code within a system that raises an error whenever an
> attempt is made to modify a literal, and is as simple as possible, but no
> simpler ;-)  Thoughts, opinions?
> 
> 
> _,,,^..^,,,_
> best, Eliot


>