code suite as first class object ?

Collapse
This topic is closed.
X
X
Collapse
 
  • Page of 1
  • Time
  • Show
Clear All
new posts
Previous template Next
  • Bengt Richter
    #1

    code suite as first class object ?

    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
    Tags: None
    • Sean Ross
      #2
      Re: code suite as first class object ?

      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(t hunk))"
      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][color=blue][color=green]
      > > switch(expr):
      > > case(val1):
      > > block1
      > > case(val2):
      > > block2
      > > default:
      > > block3
      > >[/color][/color]

      To which he added:
      [color=blue][color=green]
      > > 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.[/color][/color]

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






        Comment

        • Sean Ross
          #3
          Re: code suite as first class object ?

          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(t hunk))"
          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


            Comment

            Previous template Next
            Working...