Extended function syntax

J.Jacob joost_jacob at hotmail.com
Thu Jan 30 19:29:46 CET 2003


There is a thread on the python-dev mailing list about extended
function syntax.  It would look something like::

  def name(args,...)[expr1, expr2, ...]:
      ...body...

This made me think about the problems I encountered with implementing
UML statecharts, the kind with triggers and guards.  The transitions
from one state into another look like::

    trigger[condition]/statements
  .------------------------------->.

This is for Mealy state machines.  There are also mathematically
equivalent Moore machines without statements (they are executed when
entering a new state).  The semantics of ``trigger[condition]`` is
such that the transition is only taken when condition is true.

To implement behavior modeled by such a statechart you can take method
names with parameters as triggers, and then put lots of::

  if condition then: statements

in the method bodies.  But such code looks really ugly.

How about using the new syntax to more easily code conditions on
triggers?

There is a lot of work going on in the academic computer science
community that uses XMI to store UML models in, including behavioral
models like statecharts.  Perhaps the extended function syntax could
help to create a tool that automatically translates XMI to class
definitions?

There are lots more possibilities.  One scenario would be to help code
"asynchronous signals" more easily.  This could be something like a
"signal handler" mentioned in the [condition] part.

These are just some ideas.  I have full confidence in Guido thinking
of better ideas and making the best decisions in language design, like
he has shown us before.




More information about the Python-list mailing list