code suite as first class object ?

[Bengt Richter]

Useless example first:

def foo(x):
a = suite:
y = 1
b = suite:
y = 2
a() # equivalent effect to local y = 1 above
(a,b)[bool(x)]() # effect of suite b if bool(x), otherwise suite a
vars()[x]() # succeeds if x in ['a', 'b']
return y

Since binding of the result of suite: is in the form of an assignment, it would also be
possible to create a switch with anonymous suites directly, e.g.,

switch = [0]*2
switch[0] = suite: z = 3
switch[1] = suite: z = 4
...
switch[expr]()

or named ones in a chosen directory (of course the name 'switch' has no special status ;-)

shazam={}
shazam['one'] = suite: print 'suite one'
shazam['two'] = suite: print 'suite two'
...
shazam[suitename]() # or use shazam.get variations if desired

or as attributes?

class NS(object): pass
doatt = NS()
...
doatt.one = suite: print 'doatt_one'
doatt.two = suite: print 'doatt_two'
...
doatt.two()
getattr(doatt, attname)()

(IWT bindings in potentially non-local namespaces would generally require closures,
whereas the vars()[suitename]() usage should not, unless vars() is exported (?)).

The above suites are obviously braindead placeholders. I.e., anything legal as a "suite"
should be legal, including nested suites both old and new (i.e., under e.g., "if expr:"
or "s=suite:") Note that suite: does not introduce a new (name) scope, though one suite object
can be invoked from the body of another. I'm not sure how much new stuff this would
introduce into stack-unwinding for exceptions, but it feels like there ought to be a way
to do better than ignoring suite calls as being internal to a frame ...

Implementation would be a parameterless function which uses the *current* local namespace
as its local space. I.e., no separate frame, just a byte code to execute a local function
(pushing return byte code location) and another to return (popping byte code location and
jumping there).

This would get the performance benefit of sequence indexing or dict lookup vs if/elif/else
equivalents without incurring full function call overhead.

I posted something similar before (not the exception thing ;-), but I think this is a little
better. I haven't thought through the closure issues, but there ought to be a way to handle
them, IWT.

Anyone have a real-life example of a long chain of elifs that could be recoded for
realistic comparison?

BTW, maybe "localfun" or "localcode" or "codeblock" would be better words than "suite"?

Of course, this is just HOTTOMH, so fire away and shoot it full of holes ;-)
Maybe if something survives the flames, it could be useful.

Regards,
Bengt Richter

[Sean Ross]

I've been thinking about something like this (though not exactly) for the
last few weeks. I did a post ("PEP318 - property as decoration"), where
(amongst other things) I suggested it would be possible to define properties
cleanly using blocks and/or thunks. This idea was based on a discussion from
python-dev in January/February ("Extended Function Syntax"). Blocks and
thunks (as I saw them) seemed powerful. The way I was thinking about them,
it looked like it might be possible to define anonymous functions, and even
anonymous classes. From there, I began toying with a language design that
focused on trying to use only namespaces, bindings, generators, blocks and
thunks (oh, and numbers and strings and lists, etc). I haven't quite worked
out the kinks, but it looks something like Smalltalk with bits and pieces of
Icon, Ruby, and Python thrown in. The idea I was trying to work out was "If
Python were to add thunks (as I pictured them), how could that affect the
language? What sorts of things could I expect to see people trying with
their code?". In other words, "How bad could it get?". Here's an example:

MyClass = object with:
"MyClass = object(thunk), where object returns a class defined using
thunk"

__init__ = method with self, foo:
"__init__ = method(thunk), where method returns a method
defined using thunk"
self._foo = foo

foo = property with:
"property foo's docstring"
fget = with self:
return self._foo
fset = with self, value:
self._foo = value

bar = static, method with:
"bar = static(method(thunk))"
1.upto(10) do with i:
print "upto() yeilds %d which is passed to the
thunk. The thunk is passed to do (do(thunk)) ", \
"where it gets executed, and so you see
this!" % i
So, the language I was working out was not Python as it is now, but as it
might become should something like blocks and thunks be added. I don't find
the language terrible, but I also don't find it to be Python - and that's my
point, I suppose. I like the idea of blocks and thunks and anonymous
functions, classes, etc., but I don't like the idea that there could be more
than one way to define a function, method, or class.

If you read the python-dev discussions, the ideas presented for thunks
appear to enable macro programming as well. For instance, using Guido's
definition of thunks he was able to construct a switch statement, but not
like yours, like this:

[Guido]

switch(expr):
case(val1):
block1
case(val2):
block2
default:
block3

To which he added:
This actually makes me worry -- I didn't plan thunks to be the answer
to all problems. A new idea that could cause a paradigm landslide is
not necessarily right.

A statement I'd have to say I agree with.

[Sean Ross]

The code in the last post looked a bit messed up on my newsreader, so here
it is again:

MyClass = object with:
"""MyClass = object(thunk), where object
returns a class defined using thunk
"""
__init__ = method with self, foo:
"""__init__ = method(thunk), where method
returns a method defined using thunk
"""
self._foo = foo

foo = property with:
"property foo's docstring"
fget = with self:
return self._foo
fset = with self, value:
self._foo = value

bar = static, method with:
"bar = static(method(thunk))"
1.upto(10) do with i:
print "upto() yeilds %d which is passed to ", \
"the thunk. The thunk is passed to do ", \
"(do(thunk)), where it gets executed, ", \
"and so you see this!" % i