code suite as first class object ?

Discussion in 'Python' started by Bengt Richter, Jun 28, 2003.

  1. 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
     
    Bengt Richter, Jun 28, 2003
    #1
    1. Advertising

  2. Bengt Richter

    Sean Ross Guest

    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, Jun 29, 2003
    #2
    1. Advertising

  3. Bengt Richter

    Sean Ross Guest

    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
     
    Sean Ross, Jun 29, 2003
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. E11
    Replies:
    1
    Views:
    4,800
    Thomas Weidenfeller
    Oct 12, 2005
  2. Tony Young
    Replies:
    3
    Views:
    316
    Daniel T.
    Mar 26, 2006
  3. Krishna
    Replies:
    4
    Views:
    439
    Steven D'Aprano
    Mar 7, 2008
  4. Michael Schuerig
    Replies:
    6
    Views:
    143
    Robert Dober
    Feb 26, 2007
  5. Daniel Berger

    First stab at a weakref test suite

    Daniel Berger, Dec 21, 2007, in forum: Ruby
    Replies:
    6
    Views:
    138
    Michal Suchanek
    Dec 22, 2007
Loading...

Share This Page