This reminds me of an silly little optimization I used to use all the
times when coding in assembler on PIC MCUs.
A call followed by a return can be turned into jump. Saves one
instruction and one level on the call stack.
I think most optimizing compilers already do something of this sort, at
least in the embedded world :)
Jeethu Rao
Michael wrote:
> Hi,
>
>
> [ I'm calling this PEP thought experiment because I'm discussing language
> ideas for python which if implemented would probably be quite powerful
> and useful, but the increased risk of obfuscation when the ideas are
> used outside my expected/desired problem domain probably massively
> outweigh the benefits. (if you're wondering why, it's akin to adding
> a structured goto with context)
>
> However I think as a thought experiment it's quite useful, since any
> language feature can be implemented in different ways, and I'm wondering
> if anyone's tried this, or if it's come up before (I can't find either
> if they have...). ]
>
> I'm having difficulty finding any previous discussion on this -- I
> keep finding people either having problems calling os.exec(lepev), or
> with using python's exec statement. Neither of which I mean here.
>
> Just for a moment, let's just take one definition for one of the
> os.exec* commands:
>
> execv(...)
> execv(path, args)
>
> Execute an executable path with arguments, replacing current
> process.
> path: path of executable file
> args: tuple or list of strings
>
> Also: Note that execv inherits the system environment.
>
> Suppose we could do the same for a python function - suppose we could
> call the python function but either /without/ creating a new stack
> frame or /replacing/ the current stack frame with the new one.
>
> Anyway, I've been thinking recently that the same capability in python
> would be useful. However, almost any possible language feature:
>* Has probably already been discussed to death in the past
>* There's often a nice idiom working around the lack of said feature.
>
> So I'm more on an exploratory forage than asking for a language change
> here ;)
>
> Since os.exec* exists and "exec" already exists in python, I need to
> differentiate what I mean by a unix style exec from python. So for
> convenience I'll call it "cexe".
>
> Now, suppose I have:
> --
> def set_name():
> name = raw_input("Enter your name! > ")
> cexe greet()
>
> def greet():
> print "hello", name
>
> cexe set_name()
> print "We don't reach here"
> --
>
> This would execute, ask for the user's name, say hello to them and then
> exit - not reaching the final print "We don't reach here" statement.
>
> Let's ignore for the moment that this example sucks (and is a good example
> of the danger of this as a language feature), what I want to do here is
> use this to explain the meaning of "cexe".
>
> There's two cases to consider:
> cexe some_func_noargs()
>
> This transfers execution to the function that would normally be called
> if I simply called without using "cexe" some_func_noargs() . However,
> unlike a function call, we're /replacing/ the current thread of
> execution with the thread of execution in some_func_noargs(), rather
> than stacking the current location, in order to come back to later.
>
> ie, in the above this could also be viewed as "call without creating a
> new return point" or "call without bothering to create a new stack
> frame".
>
> It's this last point why in the above example "name" leaks between the
> two function calls - due to it being used as a cexe call.
>
> Case 2:
> given...
> def some_func_withargs(colour,tone, *listopts, **dictopts)
>
> consider...
> cexe some_func_withargs(foo,bar, *argv, **argd)
>
> This would be much the same as the previous case, except in the new
> execution point, the name colour & tone map to the values foo & bar had
> in the original context, whilst listopts and dictopts map the values
> that argv & argd had in the original content)
>
> One consequence here though is that in actual practice the final print
> statement of the code above never actually gets executed. (Much like if
> that was inside a function, writing something after "return foo", wouldn't
> be executed)
>
> The reason I'
