Kaz Kylheku wrote:
> By the way, I once made a (proprietary, closed source) Lisp dialect
> which had dynamic scope, but with proper closures!

Didn't Interlisp do that with spaghetti stacks?

"One of the most innovative of the language extensions introduced by
Interlisp was the spaghetti stack. The problem of retention (by
closures) of the dynamic function-definition environment in the presence
of special variables was never completely solved until spaghetti stacks
were invented." The Evolution of Lisp, Steele and Gabriel, 1993.

Well done with your marathon training!

On 2024-01-18, Lars Brinkhoff <lars.spam@nocrew.org> wrote:
> Kaz Kylheku wrote:
>> By the way, I once made a (proprietary, closed source) Lisp dialect
>> which had dynamic scope, but with proper closures!
>
> Didn't Interlisp do that with spaghetti stacks?

Well, yes. I think I consciously had spaghetti stacks in mind when
working on that implementation.

IIRC (I don't have the code) it may be that the variable frames were
actually just kept in the regular run-time stack, and not dynamically
allocated. Only the closing mechanism created dynamic copies.

Also, I think, when taking a closure, I didn't just blindly replicate
the chain of frames up to the capture delimiter, but flattened it down
to one environment frame.

> "One of the most innovative of the language extensions introduced by
> Interlisp was the spaghetti stack. The problem of retention (by
> closures) of the dynamic function-definition environment in the presence
> of special variables was never completely solved until spaghetti stacks
> were invented." The Evolution of Lisp, Steele and Gabriel, 1993.

Okay, so there was an awareness about spaghetti stacks solving a more
general problem; it wasn't just for the sake of continuations.

So that's what I did in that implementation: a more limited form
of the spaghetti stack technique that wouldn't support resumption
of a continuation, only visibility into dynamic environments.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On Wed, 17 Jan 2024 23:33:40 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:

>On Wed, 17 Jan 2024 20:37:43 -0000 (UTC), Kaz Kylheku wrote:
>
>> By the way, I once made a (proprietary, closed source) Lisp dialect
>> which had dynamic scope, but with proper closures!
>
>I’m just a humble Python programmer, but it seems to me there are easier
>ways of doing such things: create and instantiate a class.

Closures ARE objects - the major difference vs conventional OOP being
that closures - at runtime - can associate an arbitrary set of data
with an arbitrary set of functions.

>Then you can define methods that access and update the internal state,
>coupled with a method that says “do the actual work”. You can even manage
>that internal state via assignable “properties”, instead of explicit
>getter/setter method calls.
>
>And for added flavour, if you define a “__call__()” method that does the
>actual work, you can call the class instance as though it were a function.

Programming with closures is more like using "prototype OO". Prototype
systems don't have classes, but rather ANY object can be modified to
change its set of instance data and/or methods, and can be cloned to
create new objects of that same "type".
https://en.wikipedia.org/wiki/Prototype-based_programming

Python OO is class based. Python objects can be modified by
reflection and can be cloned ... but that is not the normal way of
defining and creating objects in Python.

There is a Python library which redefines classes and objects to
enable some prototype like behavior ... but there still is a
distinction between "class" and "object".

On Thu, 18 Jan 2024 23:39:26 -0500, George Neuner wrote:

> Programming with closures is more like using "prototype OO". Prototype
> systems don't have classes, but rather ANY object can be modified to
> change its set of instance data and/or methods, and can be cloned to
> create new objects of that same "type".

That’s true of Python, too.

On Fri, 19 Jan 2024 05:42:33 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:

>On Thu, 18 Jan 2024 23:39:26 -0500, George Neuner wrote:
>
>> Programming with closures is more like using "prototype OO". Prototype
>> systems don't have classes, but rather ANY object can be modified to
>> change its set of instance data and/or methods, and can be cloned to
>> create new objects of that same "type".
>
>That’s true of Python, too.

You can clone/copy objects in Python, but - barring use of reflection
- you can't easily change an object's *declaration*: ie. its
properties (data fields) and methods (functions). Those are tied to
the object's class.

In prototype OO you can modify any object to add, delete, change or
replace its data fields or methods. Every object then is a template
for creating new objects having the same set of fields and methods.
[You could say that every object is both a class and an instance of
that class, but really the whole notion of what it means to be a class
or a member thereof disappears.]

On Fri, 19 Jan 2024 12:11:13 -0500, George Neuner wrote:

> On Fri, 19 Jan 2024 05:42:33 -0000 (UTC), Lawrence D'Oliveiro
> <ldo@nz.invalid> wrote:
>
>>On Thu, 18 Jan 2024 23:39:26 -0500, George Neuner wrote:
>>
>>> Programming with closures is more like using "prototype OO". Prototype
>>> systems don't have classes, but rather ANY object can be modified to
>>> change its set of instance data and/or methods, and can be cloned to
>>> create new objects of that same "type".
>>
>>That’s true of Python, too.
>
> You can clone/copy objects in Python, but - barring use of reflection
> - you can't easily change an object's *declaration*: ie. its
> properties (data fields) and methods (functions). Those are tied to
> the object's class.

No they are not.

Newsgroups: comp.lang.lisp,comp.lang.python

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Thu, 18 Jan 2024 23:39:26 -0500, George Neuner wrote:
>>Programming with closures is more like using "prototype OO". Prototype
>>systems don't have classes, but rather ANY object can be modified to
>>change its set of instance data and/or methods, and can be cloned to
>>create new objects of that same "type".
>That’s true of Python, too.

Yes that's true. Forgive me guys if that's too "off topic"
in comp.lang.lisp, but it might not be obvious how to create
an object in Python and then attach fields or methods to it.
So here I humbly submit a small example program to show this.

main.py

from types import *

# create a new object
def counter_object(): pass

# attach a numeric field to the object
counter_object.counter_value = 0

# define a named function
def increment_value( self ): self.counter_value += 1

# attach the named function to the object as a method
counter_object.increment_value = \
MethodType( increment_value, counter_object )

# call the method
counter_object.increment_value()

# attach an unnamed function to the object
counter_object.get_value = \
MethodType( lambda self: self.counter_value, counter_object )

# call that method
print( counter_object.get_value() )

This program will then print "1" and a line terminator.

Newsgroups: comp.lang.lisp,comp.lang.python

On 20 Jan 2024 10:13:40 GMT, Stefan Ram wrote:

> from types import *

Death to wildcard imports!

On Fri, 19 Jan 2024 20:35:14 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:

>On Fri, 19 Jan 2024 12:11:13 -0500, George Neuner wrote:
>
>> On Fri, 19 Jan 2024 05:42:33 -0000 (UTC), Lawrence D'Oliveiro
>> <ldo@nz.invalid> wrote:
>>
>>>On Thu, 18 Jan 2024 23:39:26 -0500, George Neuner wrote:
>>>
>>>> Programming with closures is more like using "prototype OO". Prototype
>>>> systems don't have classes, but rather ANY object can be modified to
>>>> change its set of instance data and/or methods, and can be cloned to
>>>> create new objects of that same "type".
>>>
>>>That’s true of Python, too.
>>
>> You can clone/copy objects in Python, but - barring use of reflection
>> - you can't easily change an object's *declaration*: ie. its
>> properties (data fields) and methods (functions). Those are tied to
>> the object's class.
>
>No they are not.

Yes they are.

Python does share some implementation details with prototype systems:
runtime type information (including object structure) is kept as a map
(dict). However, when you modify an object with __addattr__ et al,
the object's *class* information is copied and then modified to create
a new anonymous class, and the object returned is an instance of that
new class. The original class remains unmodified and continues to be
used as long as instances of that class remain.

But Python does not actively promote the notion that objects should be
manipulated in this way. The *preferred* way is to create a new type
is to define a new named class.

In contrast, in a prototype system manipulating an object's structure
and cloning it is the ONLY way to create a new type of object. Every
object IS its own class, so when/if you modify it, you truly are
modifying the class itself.

On Sat, 20 Jan 2024 19:20:46 -0500, George Neuner wrote:

> However, when you modify an object with __addattr__ et al,
> the object's *class* information is copied and then modified to create
> a new anonymous class ...

Shut up already. And try this:

class ExampleClass :

def method(self) :
print("I am the true method.")
#end method

#end ExampleClass

def false_method() :
print("I am the impostor method.")
#end false_method

inst1 = ExampleClass()
inst2 = ExampleClass()
inst2.method = false_method

inst1.method()
inst2.method()
del inst2.method
inst2.method()

Output:

I am the true method.
I am the impostor method.
I am the true method.

On Sun, 21 Jan 2024 00:32:55 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:

>On Sat, 20 Jan 2024 19:20:46 -0500, George Neuner wrote:
>
>> However, when you modify an object with __addattr__ et al,
>> the object's *class* information is copied and then modified to create
>> a new anonymous class ...
>
>Shut up already. And try this:
>
> class ExampleClass :
>
> def method(self) :
> print("I am the true method.")
> #end method
>
> #end ExampleClass
>
> def false_method() :
> print("I am the impostor method.")
> #end false_method
>
> inst1 = ExampleClass()
> inst2 = ExampleClass()
> inst2.method = false_method
>
> inst1.method()
> inst2.method()
> del inst2.method
> inst2.method()
>
>Output:
>
> I am the true method.
> I am the impostor method.
> I am the true method.

That is not changing the object's declaration at all - it is simply
rebinding a member to a new function in one instance.

Create a new instance of ExampleClass() and it will have the original
method, not the "change" you made to inst2.

How about you try to learn something?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

...

Shut up already. And try this:

Calm down. The point that George was trying to make is that neither
Python nor Common Lisp is a prototype OO system. Prototype OO was once
(in the early 80s) a serious contender for how to design an
object-oriented language. Before Common Lisp had an object system there
were several proposals floating around, some of which were prototype
based. But I don't think any programming language ever actually wound
up using such a system.

It is true that in Python you can do this:

class ExampleClass :
def method(self) :
print("I am the true method.")

def false_method() :
print("I am the impostor method.")

inst1 = ExampleClass()
inst2 = ExampleClass()
inst2.method = false_method

inst1.method()
inst2.method()
del inst2.method
inst2.method()

Output:

I am the true method.
I am the impostor method.
I am the true method.

But consider the following:

Python 3.10.5 (v3.10.5:f37715, Jul 10 2022, 00:26:17) [GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> class Frob:
... def __len__(self):
... return 17
...
>>> x = Frob()
>>> len(x)
17
>>> x.__len__()
17
>>> x.__len__ = lambda: 23
>>> x.__len__()
23
>>> len(x)
17

Why didn't that work? Because the Python implementors knew that
assigning new methods like that was not the _normal_ way to make objects
with new behaviors. The _could_ have made that work (which would
arguably be more consistent), but in the name of efficiency they chose
not to. In a _true_ prototype system, where all new object behavior
comes from cloning followed by modification, they would not have made
that choice.

- Alan

On 2024-01-20, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On 20 Jan 2024 10:13:40 GMT, Stefan Ram wrote:
>
>> from types import *
>
> Death to wildcard imports!

I was regarded as a maverick/lunatic in the 1990's when, in the context
of C++, I called out that wholesale imports like "using std;" are
an incredibly idea, only suitable at best for throwaway test programs.

Mostly, the C++ world came around to it.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2024-01-21, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sat, 20 Jan 2024 19:20:46 -0500, George Neuner wrote:
>
>> However, when you modify an object with __addattr__ et al,
>> the object's *class* information is copied and then modified to create
>> a new anonymous class ...
>
> Shut up already. And try this:

I used Python for a total of about four or five days, yet I
managed to attach a new property at run-time to the object
coming out of Argparse (or whatever that argument parsing
thing is called).

I can't remember exactly why, but it was expedient.
The code was converted from ad-hoc argument parsing to
Argparse, and the technique helped represent some feature
of the original logic.

Python has a mechanism to attach new propeties to objects
dynamically. In that mechanism, their names appear
as strings, but then end up visible in the normal
member access syntax as obj.name.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2024-01-21, Alan Bawden <alan@csail.mit.edu> wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
> ...
>
> Shut up already. And try this:
>
> Calm down. The point that George was trying to make is that neither
> Python nor Common Lisp is a prototype OO system. Prototype OO was once
> (in the early 80s) a serious contender for how to design an
> object-oriented language. Before Common Lisp had an object system there
> were several proposals floating around, some of which were prototype
> based. But I don't think any programming language ever actually wound
> up using such a system.

Today, JavaScript is said to be prototype-based. I have no idea where
the goalposts are: is it True Scotsman's prototype-based or not.

(All I know is that I hate every aspect of the approach, in
pretty much any shape. It is a copout from doing the gruntwork of
implementing a proper object system, and that shows at every corner.)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On Sat, 20 Jan 2024 23:30:29 -0500, Alan Bawden wrote:

> >>> class Frob:
> ... def __len__(self):
> ... return 17 ...
> >>> x = Frob()
> >>> len(x)
> 17
> >>> x.__len__()
> 17
> >>> x.__len__ = lambda: 23 x.__len__()
> 23
> >>> len(x)
> 17
>
> Why didn't that work?

Not sure what you are saying didn’t “work” in this case. Monkey-patching
the member of the instance does “work”: access the member on the instance,
and you get the monkey-patched value.

Alan Bawden <alan@csail.mit.edu> writes:
>Why didn't that work?

Implicit invocations of special methods are only guaranteed
to work correctly if defined on an object's type, not in
the object's instance dictionary. (See: The Python Language
Reference, Release 3.13.0a0; 3.3.12 Special method lookup).

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>Alan Bawden <alan@csail.mit.edu> writes:
>>Why didn't that work?
>Implicit invocations of special methods are only guaranteed
>to work correctly if defined on an object's type, not in
>the object's instance dictionary. (See: The Python Language
>Reference, Release 3.13.0a0; 3.3.12 Special method lookup).

That was a rhetorical question!

To use "prototypes", you need to write a custom clone method anyway
(I just posted one to "comp.lang.python"). So, while you're at it,
you can then as well define your custom global "len" function:

def len( x ): return x.__len__()

. (It might still be some work to get the rest of the
standard library to use this definition, but now we are
talking about a library and not about a language. Yes,
the Python standard library assumes class-based objects.)

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>the Python standard library assumes class-based objects.)

Since the thread is about "binding": Python can be very
explicit when it comes to binding (should you need it).

main.py

import types

x = 2

def f():
return x

# prints "2"
print( f() )

g = types.FunctionType( f.__code__, { 'x': 4 } )

# prints "4"
print( g() )

h = types.FunctionType( f.__code__, globals() )

# prints "2"
print( h() )

def a():
x = 3

# prints "2"
print( f() )

# prints "3"
print( types.FunctionType( f.__code__, locals() )() )

# prints "2"
print( types.FunctionType( f.__code__, globals() )() )

a()

ram@zedat.fu-berlin.de (Stefan Ram) writes:

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>Alan Bawden <alan@csail.mit.edu> writes:
>>Why didn't that work?
>Implicit invocations of special methods are only guaranteed
>to work correctly if defined on an object's type, not in
>the object's instance dictionary. (See: The Python Language
>Reference, Release 3.13.0a0; 3.3.12 Special method lookup).

That was a rhetorical question!

I'm glad you recognized that. Yes, I was well aware of that quote from
the Python documentation. The real question I was asking is _why_ did
the Python implementors make that choice. It's because they weren't
trying to implement a prototype-based language!

To use "prototypes", you need to write a custom clone method anyway
(I just posted one to "comp.lang.python"). So, while you're at it,
you can then as well define your custom global "len" function:

def len( x ): return x.__len__()

. (It might still be some work to get the rest of the
standard library to use this definition, but now we are
talking about a library and not about a language. Yes,
the Python standard library assumes class-based objects.)

And you have to also define:

def add(x, y): return x.__add__(y)

And convince everybody to stop using infix notation. Or you have to
start with a base class like:

class PrototypeObject(object):
def __add__(self, x):
return self.add(x)
def __radd__(self, x):
return self.radd(x)
# As well as definitions for __sub__, __rsub__, __mul__, __rmul__,
# etc.

And convince everybody to use this class instead of the built-in
`object' class -- so that behavior modifications can be made by doing
`x.add = ...' etc.

Yes, you can do that. In fact, it works out pretty well if you really
need to do prototype-based programming for some reason. You can do
something similar in Common Lisp.

But that doesn't mean that Common Lisp and Python _are_ prototype-based
systems. Both are class-based and were engineered that way from the
very beginning. They both allow you to _emulate_ prototype-based
object-orientation, but is not the natural way to do things in either
language.

We started down this rat hole becase of the following exchange:

From: Lawrence D'Oliveiro <ldo@nz.invalid>
Date: Fri, 19 Jan 2024 05:42:33 -0000 (UTC)

On Thu, 18 Jan 2024 23:39:26 -0500, George Neuner wrote:

> Programming with closures is more like using "prototype OO". Prototype
> systems don't have classes, but rather ANY object can be modified to
> change its set of instance data and/or methods, and can be cloned to
> create new objects of that same "type".

That’s true of Python, too.

Lawrence's brief statement can be read as saying: "By that definition,
Python is prototype-based." That is how I read it initially, but I
think it's pretty clear that Python is not prototype-based, but
class-based.

But you can also read it as making the weaker claim: "Python can easily
support prototype-based programming." Which is true, as we've
demonstrated above, but perhaps not as interesting a claim, since it is
also true of some other class-based programming languages.

In any case, I think we've beaten this thread to death now.

- Alan

On Sun, 21 Jan 2024 16:18:22 -0500, Alan Bawden wrote:

> ... but I think it's pretty clear that Python is not prototype-based,
> but class-based.

Or maybe Python doesn’t easily fit into these neat pigeon holes you have
for conventional categories of “object-oriented” programming languages.
See the descriptor concept
<https://docs.python.org/3/reference/datamodel.html#descriptors>
for an illustration of what I mean.