Naked function call syntax

[Bengt Richter]

On Sat, 14 Jul 2001 13:20:49 +1000, simonb at webone.com.au wrote:

>right.
>I do this for lists:
>
> >>>def lprint(alist):
> >>>     for a in alist:
> >>>        print str(a)
>
>so that i don't get repr of elements.
>And it would be great to be able to write:
> >>> lprint alist
>just like print...
>
>Im not sure i understand the proposed resolution of
>leading '[' or '('...
>"print(1,2)" prints a tuple, so wouldn't
>you have to mark functions as "naked"
>so that a tuple would be sent as the first argument?
>
If there is a problem, it's not with print (1,2).
UIAM, print is recognized first as a special symbol
introducing a print statement. Unlike an ordinary
symbol, it is not optionally followed by a "trailer"
of (xxx) for function invocation, [xxx] for indexing,
or .NAME for attribute selection. E.g., print.NAME will get
you the same error as .NAME by itself (syntax error), not
an error that print doesn't have .NAME attribute.

Actually, now I'm thinking the change would have to be
in the 'power' term definition, to prevent gobbling multiple
lines with NEWLINE in trailer. Since you wouldn't be raising
a function body to a power, perhaps power could be changed from

    power: atom trailer* ('**' factor)*
to
    power: atom trailer* ('**' factor)* | atom trailer* arglist NEWLINE

power would then really be power_or_naked_call_ending_line
and trailer would be unchanged, which would allow you make naked
method calls too ;-) There would still be ambiguities to be resolved
in favor of the old 'clothed' call syntax.

> >>>def naked lprint(alist):
> >>>...
>
>Well, this sounds rediculous to me.
LOL, almost ROFL, when you say it ;-)

>what about:
>
> >>>def lprint alist:
> >>>...
>
I don't think you need special definition syntax. It's
not about the function itself, it's how you write the call.
And nothing should need to change about the old def or call
syntax.

The new thing would Just be that on a function call whose
normally parenthesized arg list ends the line, you'd have
the option of dropping the parens -- so long as the arg list
itself didn't start with '(' or '['.

'clothed' calls would still work as usual, because of
the precedence of the leading '('. Howver, you couldn't
make a naked call with a tuple or list as an argument. You'd
have to write foo((bar,baz)) or foo([bar,baz]). But then,
that's the way you have to write it now ;-) Conceivably,
if foo[bar,baz] produced a syntax error it would be re-interpreted
as a naked call to foo with a [bar,baz] list as argument, but
I'm not sure when that might happen.

In effect, it seems like print has a naked arg list by default,
instead of last resort.

>?
>Simon.
>
>
>Bengt Richter wrote:
>
>>Interactively, I find myself writing little things like:
>>
>>def pd(x):
>>    try:
>>        print x.__doc__
>>    except:
>>        print '(no doc string)'
>>
>>so that, e.g., I can type
>>
>>    pd(vars)
>>
>>and get formatted info. But I'm lazy enough that
>>I would like to to type just
>>    pd vars
>>
>>Is there an existing pythonic way to do this?
>>
>>If not, would there be breakage if python were modified to make
>>
>>    foo whatever-up-to-EOL
>>
>>equivalent to
>>
>>    foo(whatever-up-to-EOL)
>>
>>when it would be a syntax error otherwise? I.e., I'm wondering
>>if the grammar could be modified to do this by changing trailer
>>to accept arglist NEWLINE if _all_ else fails, and treat a match
>>as if it was an arglist. Leading '(' or '[' ambiguity would be
>>resolved in favor of normal arglist or subscriptlist.
>>
>>
>