Finding the instance reference of an object

Aaron Brady castironpi at gmail.com
Fri Nov 7 02:57:16 CET 2008


On Nov 6, 6:00 pm, Terry Reedy <tjre... at udel.edu> wrote:
> Aaron Brady wrote:
> > and you can't have languages without implementations.
>
> This is either a claim that languages are their own implementations, or
> an admission that human brains are the implementation of all languages
> thought of by human brains, coupled with a claim that there cannot be
> languages not thought of by humans, or just wrong in terms of the common
> meaning of algorithmic implementation of an interpreter.  There are many
> algorithm languages without such implementations.  They were once called
> 'pseudocode'. (I don't know if that term is still used much.)  Hence my
> oxymoronic definition, a decade ago, of Python as 'executable pseudocode'.

I was just saying that Joe has a good idea for one way to implement
Python.

> Python and C/C++ have completely different object and data models.  You
> and Joe are completely welcome to understand/model Python in terms of
> the C implementation, if you wish, but it not necessary and, I believe,
> a disservice to push such a model on beginners as *the* way to model Python.

You're asking about people's thought processes when they write a
program.  In chess, I sometimes think, "If I move here, he moves
there," etc., but not always; sometimes I just visualize pieces in
places.  In Python, if I want a function that, say, duplicates the
first and last elements of a sequence type, I visualize one parameter,
and some code that operates on it.

def duper( a ):
  a.insert( 0, a[ 0 ] )
  a.append( a[ -1 ] )

Someone else with no experience, or certain incompatible experience,
might visualize this:

def duper( a ):
  a= a[ 0 ] + a + a[ -1 ]

As you can see, they know a lot of Python already.  What are they
missing?

> > if variables can't be
> > anything but pointers, parameters are all c-b-v, and you can't
> > dereference the l-h-s of an assignment ( '*a= SomeClass()' ).
>
> I don't understand this.

If you restricted a C program as follows:
  - variables can only be pointers
  - no pointers to pointers
  - no dereferencing l-h-s of assignment statements

It would look at the very least a lot like Python, or as Joe holds,
exactly like Python.

snip.

> I disagree.  In everyday life, we have multiple names for objects and
> classes of objects.  We nearly always define procedures in terms of
> generic object classes (common nouns) rather than particular objects.
> We apply procedures by binding generic names to particular objects, by
> associating them with objects, by filling in the named blanks.  This is
> what Python does.  Except for the particular formalized syntax, there is
> nothing new, not even the idea of a specialized procedure language.

To examine the natural language (NL) equivalents of these issues a
little.

Here's a question I posed to Joe:

a) 'Fido' is a reference to a dog
b) Fido is a reference to a dog
c) 'Fido' is the name of a dog
d) Fido is the name of a dog
e) 'Fido' is a dog
f) Fido is a dog

Which are true?

I have no problems with (c) and (f), and many natural languages
(possibly being strictly spoken) do not distinguish (c) from (d).
Similarly,

Old McDonald had a dog and Bingo was it's name.
(*) Old McDonald had a dog and Bingo was it.  (* marks non-standard)
(*) Old McDonald had a dog and it was Bingo.

I want to give a code name to Fido: Rex.  What language do I use to
inform my audience ("spies"), and what statements are subsequently
true?  Then, I want to write instructions to friends on how to walk
dogs in my neighborhood, still in natural language.

_How to walk a dog_
  Take the dog out the door
  Turn right at the end of the drive
  etc.

Nothing mysterious.  Same thing with instructions for vaccinating
them.  However, if I want to model dogs, simulate them, etc., I'll
keep some running state information about them: think its chart at the
vet.

Dog:
  Fido:
    Last walked: 10 a.m.
    Needs to be walked: False

At 4 p.m., I'm going through the charts, and I notice Fido hasn't been
walked, so I change the 'Needs to be walked' entry to true.

Then some members of "spies" walks into the vet, and ask if Rex needs
to be walked.

What things in this story are names, variables, dogs, references,
objects, pointers, types, classes, procedures, functions, arguments,
parameters, formal parameters, by-value parameters, by-reference
parameters, by-share parameters, etc.?  How many names does Fido have,
what are they, what is Fido, what is Rex, etc.?  Keep in mind there
are seldom quotes in spoken language; people have to make gestures or
be explicit in such cases as they need to indicate their presence.

"Quote Fido quote is the name of a dog, but Fido is not."  (Actual
transcription.)

Keep answers to less than 500 words.  Also, reevaluate the uses of
'the' and 'a' in the multiple choice question: Is 'Fido' the name of a
dog, a name of a dog, or a name of the dog?

> def make_cookies(flour, oil, sugar, egg, bowl, spoon, cookie_pan, oven):
>      "flour, oil, and sugar are containers with respectively at least 2
> cups, 1 tablespoon, and 1/4 cup of the indicated material"
>      mix(bowl, spoon, measure(flour, '2 cups'), measure(sugar, '1/4 cup'))

yield cookies  #yum

> OK, there is one important difference.  The concrete referents for the
> parameters are non-physical information objects rather than physical
> objects.

This is actually underestimated.  Equality and identity as defined on
mathematical ("ideal") / logical objects isn't the same as our "real"
notions of them.  Words are sort of in between, giving rise to e.g.
the difference between numbers and numerals.

> >> I would say that an oject is passed, not a reference.
> > I agree, and anything else would be overcomplicated.
>
> To me, 'pass' implies movement, but in Python, objects don't really have
> a position and hence cannot move.  So I would say that an object is
> associated (with a parameter).

Further complicating matters, is the function, its parameters,
variables, code, etc. remain in existence between calls to it.  Argh!

> 'Associating' is a primitive operation for Python interpreters.

Interesting.  If I may be so bold as to ask, is it for C code, C
compilers, and/or C programs?

snip.

All due respect.



More information about the Python-list mailing list