The idea was never to start passing complex expressions around the place. It was just to allow a function to take an expression containing about one or two names, and evaluate the expression internally, so this...
>
> func(lambda foo: foo > 0)
>
> ...can become...
>
> func($foo > 0)

>>> from macropy.quick_lambda import macros, f, _
>>> map(f[_ + 1], [1, 2, 3])
[2, 3, 4]

From an external API, it seems exactly the same. From an internal point of view, you have to pass foo explicitly to the function you capture, but I'd argue that that's probably a good thing in the majority of cases. There are cases where you'd want to "evaluate the expression internally" to automagically inject identifiers into the scope of the expression, but those are few and far between.


On Wed, Mar 5, 2014 at 11:44 AM, Ryan Gonzalez <rymg19@gmail.com> wrote:
On Tue, Mar 4, 2014 at 8:36 PM, David Mertz <mertz@gnosis.cx> wrote:
On Tue, Mar 4, 2014 at 5:46 PM, Cameron Simpson <cs@zip.com.au> wrote:
>   foo = 1
>   a = $(foo + 1)
Definitely nicer. Still irrationally uncomfortable about the "$" though.
A thought, though it could break existing code (and nested tuples, alas):

    a = (( foo + 1 ))

That looks like unresolvable ambiguity to me.  I confess that I am more comfortable with '$(...)' because I'm one of those folks who actually likes bash, and uses that spelling often over there (where the meaning isn't the *same* as this, but is enough similar for the meaning to carry over)
 

But this is Python, which is 10x better. And besides, that syntax gives me GNU make nightmares.
 
Still, what does this mean?
    a = 3 + (( foo + 1 ))
I think that would need to be a syntax error, because I can't see it being
anything except nonsense otherwise.

I see it as:

Create an anonymous function object that adds foo to 1. Then, try and add 3 to that resulting object(which obviously would fail). It'd be kind of like:

a = 3 + (lambda: foo+1)

a.k.a:

def myfunc(): return foo+1
a = 3+myfunc

or(somewhat clearer in C++):

SomeType a = 3 + [&]() { return foo+1; };

It's a bit more obvious of the error in the C++ example(or, at least to me).

...
--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.



--
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated."


_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/