[Python-ideas] Infix functions

[Ron Adam]

On 02/26/2014 12:19 PM, Andrew Barnert wrote:
> On Feb 25, 2014, at 15:02, Greg Ewing<greg.ewing at canterbury.ac.nz>  wrote:
>
>> >Andrew Barnert wrote re Nick's concise lambda proposal:
>> >
>>> >>    data = using(:?.read(), open(path))
>>> >>    buf = catch(:read_file(path), (FileNotFoundError, :'')
>>> >>    b = cond(a, :1/a, :NaN)
>> >
>> >This doesn't look like Python to me. It's too cryptic,
>> >especially with the '?'.
> Yeah, that was my initial reaction to Nick's suggestion, but it's growing on me. Anyway, there's a separate thread on that, which is stalled while I gather use cases from real code. (The stdlib uses lambdas much less than user-level code does, but the docs are full of them...)
>
>> >If you think a colon in
>> >an except-expression looks too confusing, this would
>> >be far worse.
> Personally, I have no problem with the colon in the except expression.
>
>> >Also, this kind of style would make it very easy to
>> >make subtle mistakes by getting the colons in the
>> >wrong places.
> I'm not sure about that. I think in most cases, anywhere you put the colons wrong will be a SyntaxError. And most of the exceptions will be places where you should be using a full-syntax lambda or an out-of-line function anyway (e.g., in a dict mapping names to functions). But until I gather more examples I don't think I can argue that effectively.

Something I thought about when reading Gregs post is it would be nice if 
these special expressions, or complex expressions, used some sort of common 
general rules.  They would be more like macro's in that sense, but not 
completely.  But it's not that easy is it?

For example if we used an introducer.. "$" before parentheses...  $(...). 
And maybe the first word is a type or keyword, followed by a space.  No 
colon is needed there.

         $(except ...)
         $(with ...)
         $(lambda ...)
         $(_ ...)       # local lambda with no args

And ...

         $(dict ...)   dict comprehension
         $(list ...)   list comprehension
         $(gen ...)    generator expression containing yield/yield from

It's a bit more verbose which some people may like, and maybe other won't. 
(?)   Having the keyword or type fist is also not always wanted, but it 
does help self document the expression.

The difference between these and functions is that these are free to not 
evaluate a sub part until it's needed.  Functions can't do that.  And they 
aren't really objects either although they may resolve to an object.

How the rest of the expression is handles is another question.  <shrug>

What I like about this concept is it clearly separates out complex 
expressions and helps to keep the core language cleaner and easier to learn 
for beginners.

Ron


>> >It's not quite the same thing as a Lisp macro, because
>> >the onus is on the caller to remember which arguments
>> >need to be quoted. In Lisp, the macro takes care of
>> >that.
> Right, it's more like a regular function that takes sexprs, where it's up to the caller to quote them. But it's not even really a parallel with that, because this isn't quoting, it really is explicitly making a function.