Re: why brackets & commas in func calls can't be ommited? (maybe it couldbe PEP?)

[Enrico 'Mc Osten' Franchi]

<[EMAIL PROTECTED]> wrote:

> But I think in some situations Ruby allows to omit them, solving some
> of the "impossibile" problems shown in this thread. This makes Ruby a
> bit better than Python to create application-specific mini languages,
> that are quite useful in some situations.

Yes. However, Ruby parser has to resort to heuristic in many cases:



"When Ruby sees a name such as ``a'' in an expression, it needs to
determine if it is a local variable reference or a call to a method with
no parameters. To decide which is the case, Ruby uses a heuristic."

In fact it is something I don't really like about Ruby (even though I
find it useful in some cases).

This is a 'pathological example'

def a
  print "Function 'a' called\n"
  99
end


for i in 1..2
  if i == 2
print "a=", a, "\n"
  else
a = 1
print "a=", a, "\n"
  end
end


But I have to say that omitting brackets in a language such as Python or
Ruby can make the code very hardly readable. The interpreter isn't the
only one who has to resort to heuristic: everytime you read a name with
no parenthesis you may have to go back and see whether it is a bound
variable, a method (so you may have to check documentation for various
modules) or an 'invalid' variable you forgot to initialize.

In fact, when I'm reading code from a project I'm not familiar with, it
can be quite hard in the first place. 

In fact most Rubyists advice to use parentheses (unless you want to
achieve a DSL like effect, or in very simple cases like

puts s

)

The third problem I found out is related to blocks ({} and do have
different precedence order). They are only syntax errors, but I find
them annoying.

-- 
blog:  http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site:  http://www.akropolix.net/rik0/  | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: why brackets & commas in func calls can't be ommited? (maybe it couldbe PEP?)

[Bruno Desthuilliers]

[EMAIL PROTECTED] a écrit :
> I have nothing against brackets, and I think Python has used them for
> too much time to allow a so big change in its syntax.
> But I think in some situations Ruby allows to omit them,


Yes. But in Ruby, there's a clear distinction between attributes and 
methods, and attributes are always private, so you can only access them 
thru method calls. Also, Ruby's methods are not really first class 
objects - at least not the way they are in Python -, so when returning a 
'callable' object from a method, you have to call a method of the object 
(something like callable.call IIRC).


> solving some
> of the "impossibile" problems shown in this thread. This makes Ruby a
> bit better than Python to create application-specific mini languages,
> that are quite useful in some situations.

I'd say 'a bit more elegant', not necessarily 'better'. But that's of 
course very subjective, and I have far less experience with Ruby.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: why brackets & commas in func calls can't be ommited? (maybe it couldbe PEP?)

[bearophileHUGS]

I have nothing against brackets, and I think Python has used them for
too much time to allow a so big change in its syntax.
But I think in some situations Ruby allows to omit them, solving some
of the "impossibile" problems shown in this thread. This makes Ruby a
bit better than Python to create application-specific mini languages,
that are quite useful in some situations.

Bye,
bearophile

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: why brackets & commas in func calls can't be ommited? (maybe it couldbe PEP?)

[Terry Reedy]

You asked two questions; the first others have asked also.

Mathematicians sometimes use brackets to indicate function application and 
sometimes just juxtaposition.  When they do the latter and when there are 
things other than functions (to exclude pure lambda calculus), then there 
are usually (always?) typographic conventions to differentiate between 
function names and value names.

A common convention is value names one letter, function names multiple 
letters;  as in 'exp cos ln x'.  Note that the functions all take one arg. 
Another is that functions get capital letters, as in 'Fx'.

Without such differentiation, and without declaritive typing of *names*, 
the reader cannot parse a sequence of expressions into function calls until 
names are resolved into objects.  And if calls can return either callable 
or non-callable objects, as in Python, but rare in mathematics, then one 
cannot parse until calls are actually made (or at least attempted, and an 
exception raised).  I mention 'attempted' because in Python there is no 
certain way to be sure an object is callable except by calling it.  It is 
much more flexible and extensible than most math systems.

Other have alluded to this problem:  if you have 'f' mean what 'f()' now 
means, then you need another way to mean what 'f' now means, such as '`f' 
(quote f).  But again, Python names are not typed.  And how would you then 
indicate 'f()()' instead of 'f()'.  The math notations without brackets 
generally don't have to deal with callables returning callables.

I don't like typing ()s much either, but they seem necessary for Python, 
and become easier with practice.

As for ,s:  they are rather easy to type.  More importantly, they turn 
certain extraneous spaces into syntax errors instead of runtime bugs that 
might pass silently and give bad answers.  For instance, 'x_y' mistyped as 
'x y'.  Most importantly, making space syntactically significant either 
within call brackets or everywhere would require prohibiting currently 
optional spaces.  For instance, 'daffodils + crocuses' would have to be 
written 'daffodils+crocuses', like it or not.

Terry Jan Reedy



-- 
http://mail.python.org/mailman/listinfo/python-list