Fredrik Lundh wrote:
greg wrote:
If you're going to indulge in argument by authority,
you need to pick authorities that can be considered,
er, authoritative in the field concerned...
Like Barbara Liskov, who's won tons of awards for her work on computer
science and programming languages, and who was among the first to
design, implement, and formally describe a language with *exactly* the
same evaluation semantics as Python? What did she and her co-authors
have to say about the calling semantics in their new language? Let's see:
"In particular it is not call by value because mutations
of arguments performed by the called routine will be
visible to the caller. And it is not call by reference
because access is not given to the variables of the
caller, but merely to certain objects."
CLU reference manual. 1979 Google's searchable HTML version (apparently
from OCR of scan package as .pdf) with a few mis-conversions.
http://64.233.169.104/search?q=cache:iNQhnst06X8J:www.oberon2005.ru/doc/doc-mit1979-000225e.pdf
We call the argument passing technique call by sharing, because the
argument objects are shared between the caller and the called routine.
She later. in 1992, called it "pass by object" (below).
But maybe they were just ignorant, and didn't really "get" how earlier
languages worked? Let's see what Liskov has to say about that:
"The group as a whole was quite knowledgeable about languages that
existed at the time. I had used Lisp extensively and had also
programmed in Fortran and Algol 60, Steve Zilles and Craig
Schaffert had worked on PL/I compilers, and Alan Snyder had done
extensive programming in C. In addition, we were familiar with
Algol 68, EL/1, Simula 67, Pascal, SETL, and various machine
languages. Early in the design process we did a study of other
languages to see whether we should use one of them as a basis for
our work [Aiello, 1974]. We ultimately decided that none would be
suitable as a basis. None of them supported data abstraction, and
we wanted to see where that idea would lead us without having to
worry about how it might interact with pre-existing
features. However, we did borrow from existing languages. Our
semantic model is largely borrowed from Lisp; our syntax is
Algol-like."
Still think they didn't understand Algol's semantic model?
The second quote come from
A History of CLU, by Barbara Liskov 1992
http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-561.pdf
Python owes more to CLU than I realized.
"Assignment has a type-independent meaning with the heap approach;
x := e
causes x to refer to the object obtained by evaluating expression e."
"arguments are passed "by object"; the (pointer to the) object resulting
from evaluating the actual argument expression is assigned to the
formal. (Thus passing a parameter is just doing an assignment to the
formal.)"
Exactly described Python also.
"we wanted to treat built-in and user-defined types alike"
Achieved fully in 3.0. She notes a difference though: some built-in
types have literals. No user types do.
"We allow common operator symbols but these are only short forms for
what is really happening, namely a call on an operation using its full
t$o name. When the compiler encounters such a symbol, it "desugars" it
by following a simple rule: it produces t$o where t is the type of the
first argument, and o is the operation name associated with the symbol.
Thus "x + y" is desugared to "t$add(x, y)" where t is the type of x."
In CLU and Python, methods belong to the class/type rather than to the
instances (as in C++ she claims).
"""Not only is this approach simple and easy to understand, it applies
to both built-in and user-defined types uniformly. To allow sugars to be
used with a new type, the type definer need only choose the right
names for the operations. For example, to allow the use of +, he or she
names the addition operation "add." """
Also, CLU has exceptions that terminate and iterators used in for
statements.
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
