> I'm not sure that that has many advantages outside of demanding less from the runtime

MacroPy doesn't demand anything from the runtime at all. pip install macropy and you're off to the races. I'm not sure how you can get any less demanding than that.

If you really want inline functions as you described, just write a macro using an unhygienic quasiquote:

@macros.expr()
def func(tree):
  return q[log(ast[tree], "i am a cow")]

This will inline the code log(..., "i am a cow") into anywhere you call func(...). 

What you're asking for is already here, not tomorrow but today: you don't need to persuade anyone that it increases ease of understanding, or that it's a good idea, or write a PEP. 

If you think it'll be worth someone else's effort to fork the python interpreter, trying out the idea using MacroPy isn't a lot to do in advance.


On Tue, Feb 18, 2014 at 10:09 AM, Andrew Barnert <abarnert@yahoo.com> wrote:
On Feb 18, 2014, at 9:07, Alex Rodrigues <lemiant@hotmail.com> wrote:

>> Alex, can you explain the difference (if any) between your proposal and dynamic scoping?
>>
>> -- Steven
>
> Inline functions would be a bit like dynamic scoping and a bit like macros. The main difference from dynamic scoping is that they would not search up beyond their parent to find names, since they act exactly like code injected at the spot they are called it is expected that the variables they are using (like the ones in it's parent) are either locals or globals.

I don't see how that's any different from a macro.

If you're just proposing a limited form of macro that works entirely at the semantic or computational level (so it can't be used to add new syntax or do many of the other tricks that PyMacro, lisp macros, etc. do), that seems reasonable. But I don't think insisting that it's really a function, not a macro, makes it better.

> I'm not sure that that has many advantages outside of demanding less from the runtime, but that's how I imagined it.

If I remember correctly, in your proposal you wanted to be able to create these things at runtime, and convert regular functions into inline functions on the fly. If so, I think you're demanding a lot _more_ from the runtime in the service of trying to demand less. Is that a key part of your proposal?

If it's _not_ a key part of the idea, you really should play with using PyMacro (limiting yourself to pure "function-like" usage) and see if it gives you everything you need. If so, you'll have some solid examples of what this can do, why it works, how it's safer than a more general macro system like PyMacro, etc.

> IMO The biggest advantage to inline functions over other constructs is ease of understanding. We may you be used to understanding scoping after lots of programming, but it's not always intuitive. On the other hand it is extremely intuitive to understand "when you call this, all that code runs exactly as if you had typed it here".

I'm not sure that it is. And it definitely gets in the way of reading code later on. That's exactly why C++ and C added inline functions, which do _not_ use the calling or defining scope, to replace function-like macros. Stroustrop even said that if you find it necessary to #define a macro, you've found a bug either in your code or in the language. I assume he later backed down from that assertion a bit, but the basic sentiment is shared by most of the community.

It's also why later Lisp-family languages added hygienic macros either in place of or alongside nonhygienic macros.

Capturing and modifying variables from a different scope is often useful, but it's even more often a mistake. That's why Python, Ruby, C++, and many other languages require you to make it explicit (all in different ways) even for simple closures over directly visible variables.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/