Re: Mutable Bytes

>>>>> "Mark" == Mark Hahn <[email protected]> writes:
Mark> I'm not up-to-date on all the arguments pro and con on
Mark> immutability for text strings, but I'm not sure I see any
Mark> difference between text strings and binary strings.  Any
Mark> argument you make for Bytes could be made for a String.  Correct
Mark> me if I'm wrong.

Well, while, as you said, the implementation details are almost
identical, but I don't think that the way people use them are nearly
as similar, or I'm sure you wouldn't have put Bytes in Prothon at all.

I have almost no experience working directly with raw data, having
almost exclusively dealt with data on a more abstract level, so I'm
surely not the best judge. However, I tend to think of raw data very
much as a mutable thing: manipulating bodies of raw data solely by
means of cutting them up and putting them back together again
afterwards doesn't match my mental model of what I'm doing very well.
When working with text strings, this procedure makes much more sense,
since usually strings are broken up into, and pieced together from,
parts that make sense to a human, e.g. words and sentences.

As for dictionary keys, my mental model is that a string should be
'reproducible', i.e. I store a piece of information using some label
that makes sense to me (the string), and if I should be able to
retreive my stored information by typing in that label again.. That's
a good argument for using the value of String objects as dictionary
keys, and thus requiring immutability. I don't think of Bytes quite
the same way. I don't expect raw data to make sense to me in the same
way. It might make sense to me by coincidence, but that's secondary.
Thus if I were to use a Bytes object as a dictionary key, I would be
much less bothered by having it use the object ID as the key than
would be the case with strings, numbers etc.

Mark> If you are worried about inefficiency as opposed to
Mark> inconvenience, then there is going to be a fix for this in my
Mark> next rewrite of the interpreter later this year.  When you write
Mark> x = y + z the intrepreter will create a new object x that is
Mark> actually just a link to y and z without actually copying the
Mark> text from y and z. [...]

This sounds very nice. My primary concern in this particular case is
efficiency, but 'inconvenience' is also an important aspect. I don't
fully agree that it's all about convenience as such: as I've explained
above, Bytes manipulation the immutable way doesn't match my mental
model of what's going on, and thus the code I produce is less clear to
me than it could be. But this is just _my_ mental model. If mine
differs from everyone else's, then of course my ramblings should just
be ignored. :-)

Martin

-- 
Homepage:       http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iEYEABECAAYFAkEDhBYACgkQYu1fMmOQldWdzACff4wJKkkedN/XEGSb9Yq1BI8k
0osAn2kRdqgMvwEacP5SJtidajjPSML4
=iSkT
-----END PGP SIGNATURE-----