Changing global variables in tkinter/pmw callback

[Alex Martelli]

"Marcin 'Qrczak' Kowalczyk" <qrczak at knm.org.pl> wrote in message
news:slrn9d703n.fge.qrczak at qrnik.zagroda...
> Fri, 6 Apr 2001 10:45:00 +0200, Alex Martelli <aleaxit at yahoo.com> pisze:
>
> > If some place after the call you had for example a loop such as
> >     DO 10, I=1,3
> > then the loop's body would 'of course' now be executed four times,
> > for example.
> >
> > We _don't_ really want this, do we?  Numbers *had better* be
> > completely immutable objects -- programming becomes a funny
> > game indeed if the actual values of numbers start changing
> > from under our feet.
>
> I would say that if numbers were immutable, then using a numeric
> literal would have to allocate a fresh object each time, otherwise
> the semantics would be too confusing, if well defined at all.

In Python, identity of immutable objects WILL differ if the
object values differ, and it's UNDEFINED whether it will or
won't differ if the object values are equal.  You can see it
this way: 'basic' semantics is that "a fresh object" is
indeed allocated each time a literal is mentioned, BUT the
compiler/runtime system is empowered to optimize by sharing
a single immutable object for separate literals which it can
prove must lead to the same value.  It doesn't seem to me to
make the semantics at all confusing.

If you meant something different from what you just wrote
(such as "if numbers were MUTABLE", rather than "immutable"
as you said) then what I wrote still holds, but I would sure
agree that mutable number objects might make for confusing
semantics -- surely would if literals were not defined as
'generators' to be freshly executed each time, and maybe
even if they weren't.


> Immutability allows unrestricted sharing of values which look
> the same. For immutable objects generally only '==' matters, not
> 'is'. Deep copying becomes equivalent to all kinds of shallow copying
> and to rebinding a reference. Passing by value becomes equivalent to
> passing by reference.

All basically true, except I'm not too sure about deep copy
equivalence to shallow, given the generality of your assertion
about 'immutable objects'.  An object can be immutable by
immutably referring to mutable objects, after all:

>>> tup = ([], [])
>>> tup[0].append(23)
>>> tup
([23], [])

The tuple has not mutated, but it sure looks like deep vs
shallow copying it might have mattered.  We might amend your
asserted equivalence to cases where ONLY immutable objects
are involved -- *NO* mutability allowed anywhere in the
web of objects which may be referencing each other (hmmm,
not sure you can _make_ a reference cycle with immutable
objects *only* -- guess not, if you're not allowed to refer
to an object until it's "fully-built").


> In an immutable world the 'boxes' and 'post-it tags' paradigms are
> unified - to the point that some people are confused and believe
> that Python works according to the 'boxes' paradigm, until they leave
> the immutable world and want to observe mutation of an integer. They
> can't create a reference to a mutating integer, because it was not
> the integer which was mutating, only the object which contained it...

...or, vice versa, they get surprised because
    a=[]
    b=a
    a.append(23)
has (from their POV) "mutated what's in b" (thinking of b as a
box that holds a copy of what "was in a" at assignment time).

Yep, good point -- and another case where mutability, apparently
so natural a concept, yields complexity (the other, classic case
being the typestrict-OO poser "if banana IS-A fruit, how comes
bag-of-banana IS-NOT-A bag-of-fruit" -- bag mutability [ability
to insert an apple into it, for example] being the root cause).


> When a language with 'post-it tags' semantics wants to express
> boxes with changing contents, it can do it in two styles: either
> introduce a boxing mechanism for individual objects (this is what
> SML and Haskell do), or pack multiple objects into some structures
> with mutable contents (this is what Python and OCaml do). Either of
> these styles can simulate the other one.

I thought I was following you up until the middle of this
paragraph.  What's the "boxing mechanism for individual
objects" in Haskell?  I do understand (I think) how a mutable
field in a one-field structure trivially lets you "box an
individual object", a la
    type 'a ref = ref of mutable 'a
but doesn't Caml introduce further primitives for
references (how would I define := otherwise...)?


Alex