Re: Call by binding [was Re: [Tutor] beginning to code]

[Marko Rauhamaa]

Rhodri James :

> On 25/09/17 20:40, Marko Rauhamaa wrote:
>> A pointer is something that points to a data object.
>
> In that case you are using "pointer" in such an informal sense that
> making deductions from it is unlikely to be successful.

Propose a name for the concept. Candidates so far: "pointer",
"location", "address", "identity", "binding", "leash", "link".

Unfortunately, "reference" is used for something else in the language
spec.

The word "address" is used by

   "An executable operational semantics for Python"
   http://gideon.smdng.nl/wp-content/uploads/thesis.pdf>


This lengthy debate is exacerbated by the language spec pretending the
concept doesn't exist and thus doesn't need a name. However, as is
evident in the above master's thesis, you can't define Python's object
model without it.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Rhodri James]

On 25/09/17 21:00, Tim Golden wrote:
(Slight sigh). Can I step in as a list owner and ask the people who are 
so very fond of debating this topic again and again: please let it drop.


But, but... someone on the internet is wrong!

https://www.facebook.com/playingrapunzel/videos/10153716804864491/

:-)
--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Rhodri James]

On 25/09/17 20:40, Marko Rauhamaa wrote:

Rhodri James :

On 25/09/17 15:26, Marko Rauhamaa wrote:

That's not what I said. I said all expressions *evaluate to* pointers.


This may well be true in particular implementations, but it is an
implementation detail so Chris' point still stands.  Another
implementation could evaluate expressions to indices (as BCPL used to
treat its globals), pieces of string or cheese, who knows?


Those are all pointers.

A pointer is something that points to a data object.


In that case you are using "pointer" in such an informal sense that 
making deductions from it is unlikely to be successful.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Marko Rauhamaa]

Chris Angelico :

> I've explained Python's (or JavaScript's, since they're the same)
> object model to a number of novice programmers without any
> difficulties, without talking about pointers or invisible values or
> any of that junk. There are just two things to explain: the concept of
> names referring to objects, and variable scope.

The JavaScript spec wrt assignment etc is actually a bit difficult to
understand: https://www.ecma-international.org/ecma-262/5.1/>.

Scheme, which also shares the same object model with Python, has a very
down-to-earth specification that uses the term "location:"

   http://schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-6.ht
   ml#%_sec_3.4>


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Chris Angelico]

On Tue, Sep 26, 2017 at 4:25 PM, Gregory Ewing
 wrote:
> Neil Cerutti wrote:
>>
>> The quest to find a succinct way to categorize Python's argument
>> passing for non-Python programmers strikes me as a sincere effort
>> to to simplify something that just isn't simple.
>
>
> I don't see how it's useful to do that in the first place.
> Under what circumstances would you find yourself having to
> explain *just* Python parameter passing and nothing else
> about the language?

And this entire debate is ONLY about trying to explain to people who
already know some other language AND think that call-by-value and
call-by-reference are the only two options. I've explained Python's
(or JavaScript's, since they're the same) object model to a number of
novice programmers without any difficulties, without talking about
pointers or invisible values or any of that junk. There are just two
things to explain: the concept of names referring to objects, and
variable scope.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Gregory Ewing]

Neil Cerutti wrote:

The quest to find a succinct way to categorize Python's argument
passing for non-Python programmers strikes me as a sincere effort
to to simplify something that just isn't simple.


I don't see how it's useful to do that in the first place.
Under what circumstances would you find yourself having to
explain *just* Python parameter passing and nothing else
about the language?

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Bill]

Tim Golden wrote:

On 25/09/2017 20:40, Marko Rauhamaa wrote:

Rhodri James :

On 25/09/17 15:26, Marko Rauhamaa wrote:

That's not what I said. I said all expressions *evaluate to* pointers.


This may well be true in particular implementations, but it is an
implementation detail so Chris' point still stands.  Another
implementation could evaluate expressions to indices (as BCPL used to
treat its globals), pieces of string or cheese, who knows?


Those are all pointers.

A pointer is something that points to a data object.


(Slight sigh). Can I step in as a list owner and ask the people who 
are so very fond of debating this topic again and again: please let it 
drop.


Threads such as this can remain interesting when the discussion 
generates a better understanding of the subject matter as the 
contributors are forced to articulate their positions leading to some 
kind of convergence of understanding.


However, even if this were the only iteration of this debate, it would 
be clear by now that there's no chance of a simple "I see what you 
mean" moment. And this is far from the only iteration, even in the 
past few months.


I feel for your need to demonstrate the validity of your respective 
positions. But it has moved on from being an enlightening debate and 
into the realms of mere tedium.


Thanks.

TJG


Perhaps it would be better to amass examples and let them speak for 
themselves?

--
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Bill]

Chris Angelico wrote:

On Tue, Sep 26, 2017 at 5:35 AM, Marko Rauhamaa  wrote:

Chris Angelico :


On Tue, Sep 26, 2017 at 12:26 AM, Marko Rauhamaa  wrote:
Sorry, that was my bad in the terminology. But where do you get that
all Python expressions evaluate to pointers?

What do they evaluate to if not pointers? Anton's "identities" would
work, too. "Address" would do, as well. I have previously proposed the
term "leash." Call it "link" or "handle" or "arrow" if you want to.

The term used isn't important. What's important is to understand that
each expression and subexpression produces and operates on pointers.

They evaluate to objects. Not to pointers to objects. Not to
references to objects. To objects. Expressions evaluate to actual
objects, and when you assign "name = value", you bind the name to the
object that value evaluates to.

ChrisA


And when you pass a reference r to a function, a copy of the reference 
is passed. So even if you reassign *that* copy of r to refer to another 
object, upon return, r still still refers to whatever it did 
originally.  ::: case closed :::, I think.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Marko Rauhamaa]

Chris Angelico :

> On Tue, Sep 26, 2017 at 5:36 AM, Marko Rauhamaa  wrote:
>> Chris Angelico :
>>> You need *some* support for your assertion that there are pointers,
>>
>> What would convince you?
>
> Evidence, or a statement from the documentation.

I mean, what piece of Python code could decide if I'm right or wrong?


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Chris Angelico]

On Tue, Sep 26, 2017 at 5:36 AM, Marko Rauhamaa  wrote:
> Chris Angelico :
>> You need *some* support for your assertion that there are pointers,
>
> What would convince you?

Evidence, or a statement from the documentation.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Marko Rauhamaa]

Rhodri James :
> On 25/09/17 15:26, Marko Rauhamaa wrote:
>> That's not what I said. I said all expressions *evaluate to* pointers.
>
> This may well be true in particular implementations, but it is an
> implementation detail so Chris' point still stands.  Another
> implementation could evaluate expressions to indices (as BCPL used to
> treat its globals), pieces of string or cheese, who knows?

Those are all pointers.

A pointer is something that points to a data object.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Chris Angelico]

On Tue, Sep 26, 2017 at 5:35 AM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> On Tue, Sep 26, 2017 at 12:26 AM, Marko Rauhamaa  wrote:
>> Sorry, that was my bad in the terminology. But where do you get that
>> all Python expressions evaluate to pointers?
>
> What do they evaluate to if not pointers? Anton's "identities" would
> work, too. "Address" would do, as well. I have previously proposed the
> term "leash." Call it "link" or "handle" or "arrow" if you want to.
>
> The term used isn't important. What's important is to understand that
> each expression and subexpression produces and operates on pointers.

They evaluate to objects. Not to pointers to objects. Not to
references to objects. To objects. Expressions evaluate to actual
objects, and when you assign "name = value", you bind the name to the
object that value evaluates to.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Marko Rauhamaa]

Chris Angelico :

> On Tue, Sep 26, 2017 at 12:26 AM, Marko Rauhamaa  wrote:
> Sorry, that was my bad in the terminology. But where do you get that
> all Python expressions evaluate to pointers?

What do they evaluate to if not pointers? Anton's "identities" would
work, too. "Address" would do, as well. I have previously proposed the
term "leash." Call it "link" or "handle" or "arrow" if you want to.

The term used isn't important. What's important is to understand that
each expression and subexpression produces and operates on pointers.

>> It also uses circular definitions when talking about dicts and lists:
>>
>>That object is then asked to assign the assigned object to the given
>>attribute
>>
>>the sequence is asked to assign the assigned object to its item with
>>that index.
>
> Technically, that's correct. When you use a statement like:
>
> foo[bar] = quux
>
> what it does is ask the object *foo* to assign *quux* to the item
> represented by *bar*.

What is missing is the definition of that assignment in the specific
case of dicts and lists. The recursive definition must be well-founded.
It covers variables ("names") but leaves the two other fundamental cases
(dicts and lists) undefined.

(I'm actually guessing the definition is missing because the author
couldn't find good language for the cases. Apparently, "dict attribute
binding" and "list element binding" weren't attractive enough.)

> But you have yet to show how you can jump from "name binding" to
> "pointer" using anything from the Python documentation.

There's nothing to show. It's a simple matter of terminology.

"Binding" is a passable synonym for "pointer."


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Chris Angelico]

On Tue, Sep 26, 2017 at 4:30 AM, Antoon Pardon
 wrote:
> On 25-09-17 20:01, Chris Angelico wrote:
>> On Tue, Sep 26, 2017 at 3:54 AM, Antoon Pardon
>>  wrote:
>>> On 25-09-17 19:31, Chris Angelico wrote:
 If by "identity" you mean the integer values returned by id(), then
 nope, you're still wrong - there is no mapping from identities to
 values. There is a mapping from name to object/value, and from an
 object, you can determine its identity. If you like, there's a mapping
 from values to identities, but not the other way around.
>>>
>>> I'm describing this at a conceptual level.
>>
>> At what conceptual level are the identities an in-between state
>> instead of being something you see from the object?
>>
 Unless, of course, you can find something in the Python documentation
 that supports this two-step indirection?
>>>
>>> The fact that the Python documentation describes its sematics differently
>>> doesn't contradict that this is a useful model.
>>
>> You need *some* support for your assertion that there are pointers,
>> and you have absolutely none.
>
> I think you have me confused with Marko Rauhamaa. He makes an assertion
> about pointers. I don't.

My bad. It sounded like you were agreeing with Marko, and arguing the
same assertion.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Antoon Pardon]

On 25-09-17 20:01, Chris Angelico wrote:
> On Tue, Sep 26, 2017 at 3:54 AM, Antoon Pardon
>  wrote:
>> On 25-09-17 19:31, Chris Angelico wrote:
>>> If by "identity" you mean the integer values returned by id(), then
>>> nope, you're still wrong - there is no mapping from identities to
>>> values. There is a mapping from name to object/value, and from an
>>> object, you can determine its identity. If you like, there's a mapping
>>> from values to identities, but not the other way around.
>>
>> I'm describing this at a conceptual level.
> 
> At what conceptual level are the identities an in-between state
> instead of being something you see from the object?
> 
>>> Unless, of course, you can find something in the Python documentation
>>> that supports this two-step indirection?
>>
>> The fact that the Python documentation describes its sematics differently
>> doesn't contradict that this is a useful model.
> 
> You need *some* support for your assertion that there are pointers,
> and you have absolutely none.

I think you have me confused with Marko Rauhamaa. He makes an assertion
about pointers. I don't.

-- 
Antoon Pardon.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Rhodri James]

On 25/09/17 15:26, Marko Rauhamaa wrote:

Chris Angelico :


On Mon, Sep 25, 2017 at 7:41 PM, Marko Rauhamaa  wrote:

In Python, all expressions evaluate pointers.


And that's an assertion that isn't backed by anything in the Python
specification. Where do you get that all Python expressions are
pointers?


That's not what I said. I said all expressions *evaluate to* pointers.


This may well be true in particular implementations, but it is an 
implementation detail so Chris' point still stands.  Another 
implementation could evaluate expressions to indices (as BCPL used to 
treat its globals), pieces of string or cheese, who knows?



As for the specification, it doesn't make use of the word "pointer:"


There's a reason for that...


The (English) expression:

The name is bound to the object.

is just another way of saying:

A pointer to the object is stored in the variable.


It really isn't.

--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was re: [Tutor] beginning to code]

[ROGER GRAYDON CHRISTMAN]

I would claim that these two paragraphs do not agree.

What is stored in the variable in Pascal?

In declared variables and value parameters, the value itself.
Let's just temporarily stipulate that for reference parameters
and pointer variables actually store a pointer to the object.

Where is it recorded whether this is a pointer to an integer
or a float or a character or a thingamajig?

Neither in the value nor the assumed pointer to the variable.
In Pascal (and most compiled languages) that value type
is maintained separately by the compiler, and then discarded
in the compiled code.

In the case of Python, the 'pointer' you refer to also has
no type information.  Instead, the type of the value is
frequently inferred at run-time, based on additional
information stored with the value.   There is no equivalent
information available at run-time in Pascal.

Now, when you say 'Python's assignment semantics
are wholly contained by those of Pascal', please show me
the equivalent Pascal code to mimic the following
(and not by defining a brand new complex object type
in Pascal, since I am not doing so in Python).

x = 5
x = 'abc'

I think the larger discussion was about value and reference parameters.
Yes you can do both of those in Pascal.
But if you were stuck with just those two choices,
which applies to this function definition?

def add_to_self(arg):
   arg += arg
x = 'abc'
add_to_self(x)
# now x = 'abcabc'
x = 5
add_to_self(x)
# x is still 5

is 'arg' a value parameter or a reference parameter?
Can you replicate this behavior in Pascal without any if statement,
since, as you say, the semantics are wholly contained by
those of Pascal (aside from the += operator itself not
appearing in the Pascal language)

Roger Christman
Pennsylvania State Universtiy

On Mon, Sep 25, 2017 12:00 PM, python-list@python.org wrote:
>
   A pointer to the object is stored in the variable.
>
>Of course, I'm using terminology that is not conventional in Python
>circles. However, I'm doing it to demonstrate that there's nothing
>particularly different between Python's assignment semantics and those
>of, say, Pascal. Python's assignment semantics are wholly contained by
>those of Pascal.
>
>

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Antoon Pardon]

On 25-09-17 19:31, Chris Angelico wrote:
> On Tue, Sep 26, 2017 at 3:04 AM, Antoon Pardon
>  wrote:
>> On 25-09-17 16:29, Marko Rauhamaa wrote:
>>> Antoon Pardon :
>>>
 Op 25-09-17 om 15:16 schreef Marko Rauhamaa:
> No, I'm not. I'm talking about pointers in the abstract sense, both in
> case of Python and Pascal. Neither language gives any hint as to the
> physical nature of the pointer.

 Yes you are. Python doesn't have pointers at the language level. So if
 you start talking pointers you are talking about implementations
 however abstract.
>>>
>>> It is difficult to say what is the "native" Python term for the thing.
>>> "Binding," maybe? The language spec fails to give it a name.
>>>
>>> However, when comparing different languages, you had better unify the
>>> terminology or you'll be confused by purely terminological issues.
>>
>> Fine, you have two mappings, a mapping from names to identities and a
>> mapping from identities to values. In languages like C, Pascal, ...
>> an assignment changes the mapping between the identities and the
>> values. In languages like Python, Smalltalk, ... an assignment
>> changes the mapping between the names and the identities.
> 
> If by "identity" you mean the integer values returned by id(), then
> nope, you're still wrong - there is no mapping from identities to
> values. There is a mapping from name to object/value, and from an
> object, you can determine its identity. If you like, there's a mapping
> from values to identities, but not the other way around.

I'm describing this at a conceptual level.

> Unless, of course, you can find something in the Python documentation
> that supports this two-step indirection?

The fact that the Python documentation describes its sematics differently
doesn't contradict that this is a useful model.

-- 
Antoon Pardon.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Chris Angelico]

On Tue, Sep 26, 2017 at 12:26 AM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> On Mon, Sep 25, 2017 at 7:41 PM, Marko Rauhamaa  wrote:
>>> In Python, all expressions evaluate pointers.
>>
>> And that's an assertion that isn't backed by anything in the Python
>> specification. Where do you get that all Python expressions are
>> pointers?
>
> That's not what I said. I said all expressions *evaluate to* pointers.

Sorry, that was my bad in the terminology. But where do you get that
all Python expressions evaluate to pointers?

> As for the specification, it doesn't make use of the word "pointer:"
>
>https://docs.python.org/3/reference/simple_stmts.html#assignme
>nt-statements>
>
> Instead, it uses (English) expressions like:
>
>is bound to the object
>is rebound
>
> when talking about "names" (aka variables).

Yeah exactly. It doesn't say anything about them being pointers.
Because they aren't.

> It also uses circular definitions when talking about dicts and lists:
>
>That object is then asked to assign the assigned object to the given
>attribute
>
>the sequence is asked to assign the assigned object to its item with
>that index.

Technically, that's correct. When you use a statement like:

foo[bar] = quux

what it does is ask the object *foo* to assign *quux* to the item
represented by *bar*.

> The (English) expression:
>
>The name is bound to the object.
>
> is just another way of saying:
>
>A pointer to the object is stored in the variable.

Where does this come from? If the name "Rosuav" refers to me, does
that mean, in English, that there is a pointer to me stored in the
variable named "Rosuav"? English isn't implemented in C or Pascal.

> Of course, I'm using terminology that is not conventional in Python
> circles. However, I'm doing it to demonstrate that there's nothing
> particularly different between Python's assignment semantics and those
> of, say, Pascal. Python's assignment semantics are wholly contained by
> those of Pascal.

As long as you start by defining everything in terms of Pascal, yes,
you can then prove that everything is contained in Pascal semantics.
But you have yet to show how you can jump from "name binding" to
"pointer" using anything from the Python documentation.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Chris Angelico]

On Tue, Sep 26, 2017 at 3:04 AM, Antoon Pardon
 wrote:
> On 25-09-17 16:29, Marko Rauhamaa wrote:
>> Antoon Pardon :
>>
>>> Op 25-09-17 om 15:16 schreef Marko Rauhamaa:
 No, I'm not. I'm talking about pointers in the abstract sense, both in
 case of Python and Pascal. Neither language gives any hint as to the
 physical nature of the pointer.
>>>
>>> Yes you are. Python doesn't have pointers at the language level. So if
>>> you start talking pointers you are talking about implementations
>>> however abstract.
>>
>> It is difficult to say what is the "native" Python term for the thing.
>> "Binding," maybe? The language spec fails to give it a name.
>>
>> However, when comparing different languages, you had better unify the
>> terminology or you'll be confused by purely terminological issues.
>
> Fine, you have two mappings, a mapping from names to identities and a
> mapping from identities to values. In languages like C, Pascal, ...
> an assignment changes the mapping between the identities and the
> values. In languages like Python, Smalltalk, ... an assignment
> changes the mapping between the names and the identities.

If by "identity" you mean the integer values returned by id(), then
nope, you're still wrong - there is no mapping from identities to
values. There is a mapping from name to object/value, and from an
object, you can determine its identity. If you like, there's a mapping
from values to identities, but not the other way around.

Unless, of course, you can find something in the Python documentation
that supports this two-step indirection?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Antoon Pardon]

On 25-09-17 16:29, Marko Rauhamaa wrote:
> Antoon Pardon :
> 
>> Op 25-09-17 om 15:16 schreef Marko Rauhamaa:
>>> No, I'm not. I'm talking about pointers in the abstract sense, both in
>>> case of Python and Pascal. Neither language gives any hint as to the
>>> physical nature of the pointer.
>>
>> Yes you are. Python doesn't have pointers at the language level. So if
>> you start talking pointers you are talking about implementations
>> however abstract.
> 
> It is difficult to say what is the "native" Python term for the thing.
> "Binding," maybe? The language spec fails to give it a name.
> 
> However, when comparing different languages, you had better unify the
> terminology or you'll be confused by purely terminological issues.

Fine, you have two mappings, a mapping from names to identities and a
mapping from identities to values. In languages like C, Pascal, ...
an assignment changes the mapping between the identities and the
values. In languages like Python, Smalltalk, ... an assignment
changes the mapping between the names and the identities.

-- 
Antoon Pardon
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Marko Rauhamaa]

Chris Angelico :

> On Mon, Sep 25, 2017 at 7:41 PM, Marko Rauhamaa  wrote:
>> In Python, all expressions evaluate pointers.
>
> And that's an assertion that isn't backed by anything in the Python
> specification. Where do you get that all Python expressions are
> pointers?

That's not what I said. I said all expressions *evaluate to* pointers.

As for the specification, it doesn't make use of the word "pointer:"

   https://docs.python.org/3/reference/simple_stmts.html#assignme
   nt-statements>

Instead, it uses (English) expressions like:

   is bound to the object
   is rebound

when talking about "names" (aka variables).

It also uses circular definitions when talking about dicts and lists:

   That object is then asked to assign the assigned object to the given
   attribute

   the sequence is asked to assign the assigned object to its item with
   that index.


The (English) expression:

   The name is bound to the object.

is just another way of saying:

   A pointer to the object is stored in the variable.


Of course, I'm using terminology that is not conventional in Python
circles. However, I'm doing it to demonstrate that there's nothing
particularly different between Python's assignment semantics and those
of, say, Pascal. Python's assignment semantics are wholly contained by
those of Pascal.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Marko Rauhamaa]

Antoon Pardon :

> Op 25-09-17 om 15:16 schreef Marko Rauhamaa:
>> No, I'm not. I'm talking about pointers in the abstract sense, both in
>> case of Python and Pascal. Neither language gives any hint as to the
>> physical nature of the pointer.
>
> Yes you are. Python doesn't have pointers at the language level. So if
> you start talking pointers you are talking about implementations
> however abstract.

It is difficult to say what is the "native" Python term for the thing.
"Binding," maybe? The language spec fails to give it a name.

However, when comparing different languages, you had better unify the
terminology or you'll be confused by purely terminological issues.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Chris Angelico]

On Mon, Sep 25, 2017 at 7:41 PM, Marko Rauhamaa  wrote:
> Antoon Pardon :
>
>> the semantics of an assignment depends on the language
>
> I've only seen one kind of assignment in the general-purpose programming
> languages I know, maybe with the exception of Prolog and Rust.
>
> So the assignment is the same everywhere, only the evaluation model
> varies. In classic C, expressions evaluate to integers, double-precision
> floating-point numbers or pointers. In Python, all expressions evaluate
> pointers.

And that's an assertion that isn't backed by anything in the Python
specification. Where do you get that all Python expressions are
pointers? That's a construct invented specifically to shoe-horn Python
into "hey look it's pass by value". It's not the fundamental of the
language.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Antoon Pardon]

Op 25-09-17 om 15:16 schreef Marko Rauhamaa:
> Antoon Pardon :
>
>> Op 25-09-17 om 14:16 schreef Marko Rauhamaa:
>>> Python only operates with pointers. You can operate with pointers in
>>> Pascal as well.
>> You are talking about implementation details.
> No, I'm not. I'm talking about pointers in the abstract sense, both in
> case of Python and Pascal. Neither language gives any hint as to the
> physical nature of the pointer.

Yes you are. Python doesn't have pointers at the language level. So if
you start talking pointers you are talking about implementations however
abstract.

-- 
Antoon Pardon

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Marko Rauhamaa]

Antoon Pardon :

> Op 25-09-17 om 14:16 schreef Marko Rauhamaa:
>> Python only operates with pointers. You can operate with pointers in
>> Pascal as well.
>
> You are talking about implementation details.

No, I'm not. I'm talking about pointers in the abstract sense, both in
case of Python and Pascal. Neither language gives any hint as to the
physical nature of the pointer.

All Python expressions evaluate to pointers (or handles or references;
call them whatever you want). All Python "lvalues" hold pointers.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Antoon Pardon]

Op 25-09-17 om 14:16 schreef Marko Rauhamaa:
> Antoon Pardon :
>
>> Op 25-09-17 om 13:32 schreef Marko Rauhamaa:
>>> In Python, assignment "mutates the target" as well. It's only that in
>>> Python, the target is always a pointer.
>> Fine if you want to word it like that, the assignments in Pascal and
>> Python are still sufficiently different.
>>
>> If you do A := B in Pascal, you have two different entities with equal
>> values.
>>
>> If you do A = B in Python, you have one entity that is refered to by
>> two variables/names.
> Python only operates with pointers. You can operate with pointers in
> Pascal as well.

You are talking about implementation details. That under the hood
you can implement it all by manipulating bits in registers and
memory, doesn't contradict that the semantic model is different.

-- 
Antoon Pardon.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Marko Rauhamaa]

Antoon Pardon :

> Op 25-09-17 om 13:32 schreef Marko Rauhamaa:
>> In Python, assignment "mutates the target" as well. It's only that in
>> Python, the target is always a pointer.
>
> Fine if you want to word it like that, the assignments in Pascal and
> Python are still sufficiently different.
>
> If you do A := B in Pascal, you have two different entities with equal
> values.
>
> If you do A = B in Python, you have one entity that is refered to by
> two variables/names.

Python only operates with pointers. You can operate with pointers in
Pascal as well.

Say I have (in Pascal):

   new(A);
   B := A

Then, in Pascal, you have one entity that is referred to by two
variables/names.

> The difference becomes clear if you later mutate A or B. In the case
> of Pascal, you will have mutated one of two entities and the other
> entity remains the same. In the case of Python, you will have mutated
> the one entity that both A and B refer to and so the mutations will be
> visible through the other variable/name.

Continuing the Pascal example above:

   new(A);
   B := A; { one entity, two names }
   A^ := 3;{ mutate the one entity }
   writeln(B);
   A^ := 7;{ mutate the one entity again }
   writeln(B)

will output

   3
   7

(although I haven't programmed anything in Pascal for than 30 years so
my syntax may be off).


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Antoon Pardon]

Op 25-09-17 om 13:32 schreef Marko Rauhamaa:
> Antoon Pardon :
>
>> Op 25-09-17 om 11:41 schreef Marko Rauhamaa:
>>> Antoon Pardon :
>>>
 the semantics of an assignment depends on the language
>>> I've only seen one kind of assignment in the general-purpose
>>> programming languages I know, maybe with the exception of Prolog and
>>> Rust.
>> I disagree. In languages like Pascal an asignment mutates the target
>> that the left hand refers to, by copying over the value from the right
>> side. In languages like python an asignment lets the target refer to a
>> new entity.
> In Python, assignment "mutates the target" as well. It's only that in
> Python, the target is always a pointer.

Fine if you want to word it like that, the assignments in Pascal and
Python are still sufficiently different.

If you do A := B in Pascal, you have two different entities with equal
values.

If you do A = B in Python, you have one entity that is refered to
by two variables/names.

The difference becomes clear if you later mutate A or B. In the
case of Pascal, you will have mutated one of two entities and the
other entity remains the same. In the case of Python, you will
have mutated the one entity that both A and B refer to and so the
mutations will be visible through the other variable/name.

-- 
Antoon Pardon.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Marko Rauhamaa]

Antoon Pardon :

> Op 25-09-17 om 11:41 schreef Marko Rauhamaa:
>> Antoon Pardon :
>>
>>> the semantics of an assignment depends on the language
>> I've only seen one kind of assignment in the general-purpose
>> programming languages I know, maybe with the exception of Prolog and
>> Rust.
>
> I disagree. In languages like Pascal an asignment mutates the target
> that the left hand refers to, by copying over the value from the right
> side. In languages like python an asignment lets the target refer to a
> new entity.

In Python, assignment "mutates the target" as well. It's only that in
Python, the target is always a pointer.

Here's proof (up to isomorphism):

   >>> x = object()
   >>> y = object()
   >>> id(x)
   139719622467712
   >>> x = y
   >>> id(x)
   139719622467728


Meaning. Before:

   +-- x --+
   |139719622467712|
   +---+

After:

   +-- x --+
   |139719622467728|
   +---+

So we can see the contents of x have been mutated.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Antoon Pardon]

Op 25-09-17 om 11:41 schreef Marko Rauhamaa:
> Antoon Pardon :
>
>> the semantics of an assignment depends on the language
> I've only seen one kind of assignment in the general-purpose programming
> languages I know, maybe with the exception of Prolog and Rust.

I disagree. In languages like Pascal an asignment mutates the target that the
left hand refers to, by copying over the value from the right side. In
languages like python an asignment lets the target refer to a new entity.

-- 
Antoon Pardon.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Marko Rauhamaa]

Antoon Pardon :

> the semantics of an assignment depends on the language

I've only seen one kind of assignment in the general-purpose programming
languages I know, maybe with the exception of Prolog and Rust.

So the assignment is the same everywhere, only the evaluation model
varies. In classic C, expressions evaluate to integers, double-precision
floating-point numbers or pointers. In Python, all expressions evaluate
pointers.

For example, in C, the expression

1 + 2

takes two integers and produces a third one. By contrast, the same
Python expression takes two pointers and produces a third one (while
possibly generating a number of objects in the process).

Analogously, C lvalues can store various types of value. In Python, all
"lvalues" store a pointer.

I haven't wanted to use the word "value" above because it is ambiguous
and confusing in the context of this discussion.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Antoon Pardon]

Op 25-09-17 om 00:39 schreef Gregory Ewing:
> Dennis Lee Bieber wrote:
>> "Binding" itself tends to be Python specific terminology -- in
>> that it
>> is the parameter /name/ that gets bound/attached to the argument
>> /object/.
>> It is the same method as used in any Python "assignment" statement,
>
> Which is why I think "call by assignment" would be
> a much better term!
>
But since the semantics of an assignment depends
on the language, "call by assignment" says nothing
abouth the semantics of the parameter passing.

-- 
Antoon Pardon

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Gregory Ewing]

Steve D'Aprano wrote:

I think that suffers from the same problem as "call by binding" -- assignment is
too general a word.


If you're learning a new language, you're almost certainly
going to learn how assignment works in that language before
you get as far as worrying about parameter passing. If not,
you need to find out.

The only case where it wouldn't be appropriate is if the
language doesn't have assignment, in which case "call by
binding" or whatever terminology it uses for naming things
would be better.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Gregory Ewing]

Dennis Lee Bieber wrote:

Though "assignment" differs so much between languages


That's the point of the term -- it's the same as whatever
assignment does in the language concerned.

This is true of *every* language I know of that uses the
term "call by value" in its official documentation. It's
also true of those that use some other term such as
"call by object" or "call by binding".

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Steve D'Aprano]

On Mon, 25 Sep 2017 08:39 am, Gregory Ewing wrote:

> Dennis Lee Bieber wrote:
>> "Binding" itself tends to be Python specific terminology -- in that it

"Binding" is certainly not Python-specific:

https://en.wikipedia.org/wiki/Name_binding

and here's an example of the term in use:

https://www.gnu.org/software/sather/docs-1.2/tutorial/fortran-names.html


>> is the parameter /name/ that gets bound/attached to the argument /object/.
>> It is the same method as used in any Python "assignment" statement,
> 
> Which is why I think "call by assignment" would be
> a much better term!

I think that suffers from the same problem as "call by binding" -- assignment is
too general a word.

The Pascal assignment:

a := b;

copies the value of b to the storage position represented by a. That's precisely
the same thing that occurs when you call func(b), so one might equally say that
Pascal was call by assignment. Likewise for C assignment.

Pascal doesn't have "reference variables", so there is no assignment analogue to
calling a function with a var parameter. But C++ does have reference variables,
to we can say that assignment:

a = b;

is the same as function call func(b) regardless of whether C++ is using by-value
or by-reference semantics.


So I believe that either "call by binding" or "call by assignment" could both
equally apply to any and all languages with function parameters, regardless of
implementation or the language's defined semantics.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Steve D'Aprano]

On Mon, 25 Sep 2017 01:56 am, bartc wrote:

>> The point I am making is that we could describe just about any and all
>> languages with functions "call by binding", whether they are call by value
>> like C, call by reference like Fortran, call by need like Haskell, or call by
>> sharing like Python.
>
> Then 'binding' is either ill-defined or used wrongly.

No, binding is a perfectly fine word. It is just too generic to be helpful here.

In Pascal or C:

a := b;
a = b;

the compiler binds a copy of the value*of b to the identifier a. In C++ were we
have reference variables:

a = b;

will either bind a copy of b to a, same as C, or bind a reference to b to a
(thus making a an alias to b).

In Python:

a = b

binds the value of b to a, without copying.

If it weren't too late to change decades of use, I'd say that "pass by value"
should be called "pass by copying".

The nature of the binding can differ: Pascal and C use the "variables are a
numbered box" model, while Python uses the "variables are one end of piece of
string tied to the object" model.

Name binding is a generic term, like assignment, which doesn't really hint at
how the assignment is done. All it really means is that the R-value (the right
hand side of the assignment, an expression or literal or value of some sort) is
associated with the L-value (the left hand side of the assignment, a variable
name, or identifier, of some sort).

By the way, the model of "pieces of string" to describe Python's assignment
model leaks too. (All models leak, to a lesser or greater degree.) The problem
with the model is that if you tied a piece of string to an object, the object
can follow the string backwards to find out its name (or names). But in Python,
objects cannot do that: they have no way of telling what names they are known
by, or even how many names there are.

(There may be clever tricks you can play with the garbage collector or debugger,
but that's not part of Python-the-language, that's a compiler-specific hook
which can peer into the implementation.)


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Gregory Ewing]

Dennis Lee Bieber wrote:

"Binding" itself tends to be Python specific terminology -- in that it
is the parameter /name/ that gets bound/attached to the argument /object/.
It is the same method as used in any Python "assignment" statement,


Which is why I think "call by assignment" would be
a much better term!

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[bartc]

On 24/09/2017 15:49, Steve D'Aprano wrote:

On Mon, 25 Sep 2017 12:35 am, Stefan Ram wrote:


   WRT to assertions about Python, I try to base them on the
   "The Python Language Reference, Release 3.6.0" (PRL).

   So, WRT to parameter passing, I would use this part of the PRL:

   »The following constructs bind names: formal parameters
   to functions,« PRL 4.2.1

   . Therefore, what Python does, I'd call »call by binding«.


I am not aware of "call by binding" being a well-known or recognised term. Did
you make it up?

Also, the problem is that *any* form of function call binds *something* to the
function parameters. If we consider the Pascal declaration:

procedure proc(x: integer; var y: integer);


and then we call it:

var
   a, b: integer;
begin
   a := 1;
   b := 2;
   proc(a, b);
end.


then 1 is bound to x and 2 is bound to y. They happen to exist in different
scopes (x is local to proc, the *name* y is local to proc, but the variable is
bound to y is global) but that's not important.

The point I am making is that we could describe just about any and all languages
with functions "call by binding", whether they are call by value like C, call
by reference like Fortran, call by need like Haskell, or call by sharing like
Python.

Then 'binding' is either ill-defined or used wrongly.

Imagine that each name (a,b,x,y) is a little box.

In Pascal, the boxes for a and b contain 1 and 2 respectively. For x and 
y, they contain pointers (dereferenced behind the scenes). Fortran is 
similar (or Fortran IV was; I don't know modern ones). C works the same 
way: every variable has a box, and that box directly contains a value.


In Python, those boxes don't contain anything, except one end of a piece 
of string. The other end is attached to an object.


When you pass a variable to a function like this:

 def fn(X):

 A=1
 fn(A)

Then X gets set up with a string which has the same object at the other 
end as A. (And the object might have a reference count to reflect that 
extra string.)


This is why you can't change A in the caller as there is no way to get 
from X's box to A's box. And the strings to the object are one-way.


In the case of fn(A+2), a new object is created (with value '3', or an 
existing '3' might be used), a new string is attached to it, and the 
other is attached to X.


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list