[Python-ideas] Function composition (was no subject)

Douglas La Rocca larocca at abiresearch.com
Sun May 10 20:40:25 CEST 2015


I agree an operator is really unnecessary, especially because parens would be needed anyway for subexpressions. A LISP-like syntax would work better than something trying to imitate Haskell.

    make_breakfast = (make_spam make_eggs(2, 'overeasy') make_cheese)
    make_breakfast()

It also has the sense of collecting and reifying a series of functions rather than declaring a tuple or list or some other data structure. Why bother with the left/right associative issues of infix operators?

Suppose you wanted a simple quick composition of a few functions where the expression would be called right away. With infix it might look like 

    (list @ sorted @ ','.join)('a string of chars to be sorted, then joined on commas')

But you already have the parens so why not just

    (list sorted ','.join)('a string ...')

On May 10, 2015, at 1:53 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> 
> Gregory Salvan writes:
> 
>> Nobody convinced by arrow operator ?
>> 
>> like: arg -> spam -> eggs -> cheese
>> or cheese <- eggs <- spam <- arg
> 
> Yuck.  There are living languages (R) that use an arrow as an
> assignment operator, and others (or perhaps you consider C a zombie
> language <wink/>) that uses one as a member operator.  I would prefer
> the C++ pipe operators, ie, << and >>.
> 
> But that's just bikeshedding a moot point; I doubt most people would
> be favorable to introducing more operator symbols for this purpose,
> and I personally would be opposed.  If functools was more popular and
> its users were screaming for operators the way the numerical folk
> screamed for a matrix multiplication operator, I'd be more sympathetic.
> But they're not screaming that I can hear.
> 
> To give an idea of how difficult it is to get an operator added, it
> took at least a decade to get the matrix multiplication operator added
> after it was first proposed, and two of the key steps were first the
> introduction of unary "@" for decorator application (another case that
> screamed for a new operator), and then the proponents dropping the
> "@@" operator from their proposal.
> _______________________________________________
> 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/


More information about the Python-ideas mailing list