Extended function syntax

[Michael Hudson]

joost_jacob at hotmail.com (J.Jacob) writes:

> 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 roughly translates to

def name(args, ...):
    ...body...
name = expr2(expr1(name))

[snippo]
> How about using the new syntax to more easily code conditions on
> triggers?

If you can code functions you can whack in the filter list to do that,
then it can.

If you can't, then you'd might want to explain what the heck you mean,
because:

> 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?

contains more words I don't understand more densely packed than I've
seen in some time.

> 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.

Again, examples please.

> 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.

He does usually manage that.

Cheers,
M.

-- 
  Screaming 14-year-old boys attempting to prove to each other that
  they are more 3133t than j00.
         -- Reason #8 for quitting slashdot today, from
            http://www.cs.washington.edu/homes/klee/misc/slashdot.html