[Python-ideas] Inline Function - idea

[Haoyi Li]

> 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 at yahoo.com> wrote:

> On Feb 18, 2014, at 9:07, Alex Rodrigues <lemiant at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140218/c42a80f6/attachment.html>