Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #21745 > unrolled thread

Why not use juxtaposition to indicate function application

Back to article view | Back to comp.lang.python

Contents

  Why not use juxtaposition to indicate function application Ray Song <emacsray@gmail.com> - 2012-03-16 20:45 +0800
    Re: Why not use juxtaposition to indicate function application "bruno.desthuilliers@gmail.com" <bruno.desthuilliers@gmail.com> - 2012-03-16 06:14 -0700
      Re: Why not use juxtaposition to indicate function application Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-16 17:00 +0100
        RE: Why not use juxtaposition to indicate function application "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-03-16 16:13 +0000
          Re: Why not use juxtaposition to indicate function application Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-16 17:31 +0100
            Re: Why not use juxtaposition to indicate function application Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-16 16:45 +0000
              Re: Why not use juxtaposition to indicate function application Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-16 18:18 +0100
              Re: Why not use juxtaposition to indicate function application Ian Kelly <ian.g.kelly@gmail.com> - 2012-03-16 11:59 -0600
              Re: Why not use juxtaposition to indicate function application Serhiy Storchaka <storchaka@gmail.com> - 2012-03-16 22:57 +0200
              Re: Why not use juxtaposition to indicate function application Chris Rebert <clp2@rebertia.com> - 2012-03-16 14:02 -0700
              Re: Why not use juxtaposition to indicate function application Serhiy Storchaka <storchaka@gmail.com> - 2012-03-17 00:14 +0200
            Re: Why not use juxtaposition to indicate function application Tony the Tiger <tony@tiger.invalid> - 2012-03-16 16:55 -0500
      Re: Why not use juxtaposition to indicate function application Terry Reedy <tjreedy@udel.edu> - 2012-03-17 00:38 -0400
    Re: Why not use juxtaposition to indicate function application "Colin J. Williams" <cjw@ncf.ca> - 2012-03-16 11:06 -0400
    Haskellizing python (was Why not use juxtaposition to indicate function application) rusi <rustompmody@gmail.com> - 2012-03-16 22:26 -0700
    Re: Why not use juxtaposition to indicate function application Larry Hudson <orgnut@yahoo.com> - 2012-03-16 23:39 -0700

#21745 — Why not use juxtaposition to indicate function application

I confess i've indulged in Haskell and found
    f a
more readable than
    f(a)

And why aren't functions curried (partially applied function is another function which takes the rest arguments) by default?


Thanks in advance for any suggestions.

--
Ray

[toc] | [next] | [standalone]

#21751

On Mar 16, 1:45 pm, Ray Song <emacs...@gmail.com> wrote:
> I confess i've indulged in Haskell and found
>     f a
> more readable than
>     f(a)

Hmmm... What about:

    f a b

versus

    f(a(b))

or was it supposed to be read as

    f(a)(b)


or as

   f(a, b)

?-)



> And why aren't functions curried (partially applied function is another function which takes the rest arguments) by default?


If you're asking "why isn't Python like Haskell", the obvious answer
is, well, "because Python is not Haskell" ;)

Remember that Pythons is first and foremost an object-oriented
language, where most of the support for functional idioms comes from
the underlying object model. functions are central to fp, objects are
central to OOP, so better to use objects than functions (hint: there's
a builtin "partial" type).

[toc] | [prev] | [next] | [standalone]

#21754

On 3/16/2012 14:14, bruno.desthuilliers@gmail.com wrote:
> On Mar 16, 1:45 pm, Ray Song<emacs...@gmail.com>  wrote:
>> I confess i've indulged in Haskell and found
>>      f a
>> more readable than
>>      f(a)
>
> Hmmm... What about:
>
>      f a b
>
> versus
>
>      f(a(b))
>
> or was it supposed to be read as
>
>      f(a)(b)
>
>
> or as
>
>     f(a, b)
>
> ?-)

That would be
   f (a b)          # Haskell
   f(a(b))          # Python

Kiuhnm

[toc] | [prev] | [next] | [standalone]

#21755

> >> I confess i've indulged in Haskell and found
> >>      f a
> >> more readable than
> >>      f(a)
> >
> > Hmmm... What about:
> >
> >      f a b
> >
> > versus
> >
> >      f(a(b))
> >
> > or was it supposed to be read as
> >
> >      f(a)(b)
> >
> >
> > or as
> >
> >     f(a, b)
> >
> > ?-)
> 
> That would be
>    f (a b)          # Haskell
>    f(a(b))          # Python

I have not used Haskell so far, but in this case I think I prefer the
'Explicit is better than implicit.'

I would probably always forget if it should be 

f a b 

or

f ( a b )

Not to mention the first line look like text rather than a function call
because my mind tends to filter out whitespaces like that when reading.
I blame variable width fonts (and the mind being a strange thing).


Ramit


Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology
712 Main Street | Houston, TX 77002
work phone: 713 - 216 - 5423

--
This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  

[toc] | [prev] | [next] | [standalone]

#21759

On 3/16/2012 17:13, Prasad, Ramit wrote:
>>>> I confess i've indulged in Haskell and found
>>>>       f a
>>>> more readable than
>>>>       f(a)
>>>
>>> Hmmm... What about:
>>>
>>>       f a b
>>>
>>> versus
>>>
>>>       f(a(b))
>>>
>>> or was it supposed to be read as
>>>
>>>       f(a)(b)
>>>
>>>
>>> or as
>>>
>>>      f(a, b)
>>>
>>> ?-)
>>
>> That would be
>>     f (a b)          # Haskell
>>     f(a(b))          # Python
>
> I have not used Haskell so far, but in this case I think I prefer the
> 'Explicit is better than implicit.'

Are you sure that
   "call the function f with the params a and b"
is better than
   f a b
or
   f(a,b)
?

> I would probably always forget if it should be
>
> f a b
>
> or
>
> f ( a b )

You wouldn't, because Haskel's way is more regular and makes a lot of 
sense: parentheses are for grouping and that's it.

Kiuhnm

[toc] | [prev] | [next] | [standalone]

#21760

On Fri, 16 Mar 2012 17:31:06 +0100, Kiuhnm wrote:

> You wouldn't, because Haskel's way is more regular and makes a lot of
> sense: parentheses are for grouping and that's it.

If f is a function which normally takes (for the sake of the argument) 
one argument, then f would call the function with no arguments (which may 
return a curried function, or may apply default arguments, or perhaps 
raise an exception). So how would you refer to the function itself 
without calling it?



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#21766

On 3/16/2012 17:45, Steven D'Aprano wrote:
> On Fri, 16 Mar 2012 17:31:06 +0100, Kiuhnm wrote:
>
>> You wouldn't, because Haskel's way is more regular and makes a lot of
>> sense: parentheses are for grouping and that's it.
>
> If f is a function which normally takes (for the sake of the argument)
> one argument, then f would call the function with no arguments (which may
> return a curried function, or may apply default arguments, or perhaps
> raise an exception). So how would you refer to the function itself
> without calling it?

Thanks to Referential Transparency, a function with no params is a constant.
But that's a good observation. It would cause some problems in Python. 
ML languages use the empty tuple: f().

Kiuhnm

[toc] | [prev] | [next] | [standalone]

#21769

On Fri, Mar 16, 2012 at 10:45 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Fri, 16 Mar 2012 17:31:06 +0100, Kiuhnm wrote:
>
>> You wouldn't, because Haskel's way is more regular and makes a lot of
>> sense: parentheses are for grouping and that's it.
>
> If f is a function which normally takes (for the sake of the argument)
> one argument, then f would call the function with no arguments (which may
> return a curried function, or may apply default arguments, or perhaps
> raise an exception). So how would you refer to the function itself
> without calling it?

A partial application of f with no arguments is still just f.

[toc] | [prev] | [next] | [standalone]

#21778

16.03.12 18:45, Steven D'Aprano написав(ла):
> If f is a function which normally takes (for the sake of the argument)
> one argument, then f would call the function with no arguments (which may
> return a curried function, or may apply default arguments, or perhaps
> raise an exception). So how would you refer to the function itself
> without calling it?

lambda:f

[toc] | [prev] | [next] | [standalone]

#21780

On Fri, Mar 16, 2012 at 1:57 PM, Serhiy Storchaka <storchaka@gmail.com> wrote:
> 16.03.12 18:45, Steven D'Aprano написав(ла):
>> If f is a function which normally takes (for the sake of the argument)
>> one argument, then f would call the function with no arguments (which may
>> return a curried function, or may apply default arguments, or perhaps
>> raise an exception). So how would you refer to the function itself
>> without calling it?
>
> lambda:f

Doesn't help; wouldn't the lambda be implicitly called?

Cheers,
Chris

[toc] | [prev] | [next] | [standalone]

#21783

16.03.12 23:02, Chris Rebert написав(ла):
> On Fri, Mar 16, 2012 at 1:57 PM, Serhiy Storchaka<storchaka@gmail.com>  wrote:
>> lambda:f
>
> Doesn't help; wouldn't the lambda be implicitly called?

No, the lambda is only for declaration. I prefer to use braces for 
lambda syntax, it will be fine with 'if' and 'while' functions.

But all this for some other, fictitious, language, not for Python.

[toc] | [prev] | [next] | [standalone]

#21781

On Fri, 16 Mar 2012 17:31:06 +0100, Kiuhnm wrote:

> and makes a lot of
> sense:

No, in here it doesn't, since THIS is a Python group, NOT a Haskel group!


 /Grrr
-- 
          ___                  ___
 (\_--_/)  | _ ._    _|_|_  _   |o _  _ ._
 ( 9  9 )  |(_)| |\/  |_| |(/_  ||(_|(/_|
 stripes are forever - as overripe ferrets

[toc] | [prev] | [next] | [standalone]

#21797

On 3/16/2012 9:14 AM, bruno.desthuilliers@gmail.com wrote:
> On Mar 16, 1:45 pm, Ray Song<emacs...@gmail.com>  wrote:
>> I confess i've indulged in Haskell and found
>>      f a
>> more readable than
>>      f(a)
>
> Hmmm... What about:
>
>      f a b
>
> versus
>
>      f(a(b))
>
> or was it supposed to be read as
>
>      f(a)(b)
>
>
> or as
>
>     f(a, b)
>
> ?-)

One also has to consider Python calls with *args, **kwds, and arg=obj. 
These are all compile-time SyntaxErrors unless inside parens that follow 
a expression.

Also, function calls, especially in a functional language without 
side-effects, do not usually occur in isolation.
'f(a) + 3' would have to be written as '(f a) + 3', so saving of parens 
anyway.

Also, is 'f a - 2' f(a -2) or f(a, -2)? A new precedence rule is needed 
to disambiguage.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#21753

On 16/03/2012 8:45 AM, Ray Song wrote:
> I confess i've indulged in Haskell and found
>      f a
> more readable than
>      f(a)
>
> And why aren't functions curried (partially applied function is another function which takes the rest arguments) by default?
>
>
> Thanks in advance for any suggestions.
>
> --
> Ray
+1

Colin W.

[toc] | [prev] | [next] | [standalone]

#21800 — Haskellizing python (was Why not use juxtaposition to indicate function application)

On Mar 16, 5:45 pm, Ray Song <emacs...@gmail.com> wrote:
> I confess i've indulged in Haskell and found
>     f a
> more readable than
>     f(a)
>
> And why aren't functions curried (partially applied function is another function which takes the rest arguments) by default?
>
> Thanks in advance for any suggestions.
>
> --
> Ray

In Haskell
a b c d is short for (((a b) c) d)

This works nicely when the latter is commonly required, as for example
happens in a language where what one may call 'the currying
convention' is the default.
It fails when one wants the opposite convention -- a (b (c (d))) --
which may be called the 'function-composition convention.'

The fact that the default convention in haskell is not always a good
idea is seen in the existence of a special application operator $ with
low precedence which allows
a (b (c (d))) to be written as a $ b $ c $ d

It is another matter: as someone pointed out that () is overloaded in
python to denote:
- function application
- tupling
- grouping

Comes from the hegemony of ASCII.
A from-first-principles unicode language would use more of these:
http://xahlee.org/comp/unicode_matching_brackets.html

[toc] | [prev] | [next] | [standalone]

#21804

On 03/16/2012 05:45 AM, Ray Song wrote:
> I confess i've indulged in Haskell and found
>      f a
> more readable than
>      f(a)
>
> And why aren't functions curried (partially applied function is another function which takes the rest arguments) by default?
>
>
> Thanks in advance for any suggestions.
>
> --
> Ray

My suggestion is that your question is irrelevant -- Python and Haskell are two different 
languages each with different syntax rules and coming from different backgrounds.  I would say 
that trying to make any language look like some other is, at best, misguided.  Simply learn, and 
get used to, the language you're using AS IT IS DEFINED, not as you think it should be.  If you 
want to combine the features of two different languages, write a new one -- don't expect that 
existing languages are going to change due to someone's whim.  To expect otherwise is simply a 
waste of time.

As to readability, I would suggest that that's more a function of what you're used to than any 
inherent language syntax rules.

If my comments seem harsh -- sorry 'bout that.  I'm old, and sometimes tend to be a curmugeon.

And as a completely irrelevant aside concerning readability:
Is anyone familiar with the IOCCC (International Obfuscated C Coding Contest)?  The object is to 
write the most obscure, but functional, C code possible.  I haven't looked at any of this for 
many years myself, but I just Googled it to see that this contest is still going on.  Anyone 
familiar with C might find it amusing to take a look...

      -=- Larry -=-

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web