I finally did my homework. Many languages have been presented as example of optional parenthesis, and not posing ambiguity problems. As I'm not a specialist of such languages, I wanted to do some homework and check what is the reality.

See for instance http://forum.dlang.org/thread/doeutcaammauwgaskawl@forum.dlang.org?page=2#post-ju0d0o:241bvh:241:40digitalmars.com for example of such claim.

1/ Ruby.

In Ruby, method are called without (). This is not ambiguous as fields are always private.

2/ Scala.

In scala, the method name is evaluated to the method itself. If this ends up being a NOOP, then the function is evaluated. See example below :

scala> def method1() = { println("method1") }
method1: ()Unit

scala> method1
method1

scala> method1()
method1

scala> def method2(f: () => Unit) = { f() }
method2: (f: () => Unit)Unit

scala> method2
<console>:9: error: missing arguments for method method2;
follow this method with `_' if you want to treat it as a partially applied function
              method2
              ^

scala> method2(method1)
method1

scala> method2(method1())
<console>:10: error: type mismatch;
 found   : Unit
 required: () => Unit
              method2(method1())
                             ^

As we can see, mthod1 is evaluated only when simply returning the function is a NOOP.

3/ Haskell

In haskell, all functions are pure, which make the conflation between the function and its result possible in an unambiguous manner.

4/ Coffescript

Example given on that page http://coffeescript.org/ tends to show that the behavior is similar to scala's. Note function square that is stored into a structure as a function, and not evaluated.

It seems that none does what D try to achieve.

On Monday, 4 February 2013 at 03:34:34 UTC, deadalnix wrote:
> I finally did my homework. Many languages have been presented as example of optional parenthesis, and not posing ambiguity problems.

How many of those languages allow you to:

1. Pass things by reference

2. Take addresses of expressions

?

On Monday, February 04, 2013 04:34:32 deadalnix wrote:
> 3/ Haskell
> 
> In haskell, all functions are pure, which make the conflation between the function and its result possible in an unambiguous manner.

Haskell doesn't even really have variables per se. It's more like they're functions with no arguments. The functional world - especially a purely functional world - is a very different place from that of a systems programming language. And there are no parens on functions in haskell of any kind to begin with. The syntax isn't C-like at all. So, I don't think that it's really a valid comparison. The real question is what's happened with C-like languages that have attempted to make parens on function calls optional. I don't know enough about the other languages that you list though to say whether they would qualify.

- Jonathan M Davis

On 2013-02-04 04:34, deadalnix wrote:
> I finally did my homework. Many languages have been presented as example
> of optional parenthesis, and not posing ambiguity problems. As I'm not a
> specialist of such languages, I wanted to do some homework and check
> what is the reality.
>
> See for instance
> http://forum.dlang.org/thread/doeutcaammauwgaskawl@forum.dlang.org?page=2#post-ju0d0o:241bvh:241:40digitalmars.com
> for example of such claim.
>
> 1/ Ruby.
>
> In Ruby, method are called without (). This is not ambiguous as fields
> are always private.

I can elaborate a bit about Ruby. In Ruby it's possible to call a method with parentheses regardless if it takes arguments or not.

It's correct that fields are always private. Inside a class fields always start with an at sign, so there's conflict there. But there is a chance of conflict for methods called without parentheses and local variables. Example:

class Bar
  def foo; end

  def bar
    foo = 3
    a = foo # local variable
  end
end

In the above example, if a local variable is declared with the same name as a method it will always refer to the local variable, just as in D.

Callable objects. There is no conflict with callable objects since those use a different syntax to invoke the object:

foo = lambda { }
foo.call


> 4/ Coffescript
>
> Example given on that page http://coffeescript.org/ tends to show that
> the behavior is similar to scala's. Note function square that is stored
> into a structure as a function, and not evaluated.

In CoffeeScript it's only legal to call a function without parentheses if it takes at least one argument. Example:

foo = -> console.log "asd"

bar = foo # refers to the "foo" function
bar = foo() # calls the "foo" function

x = (y) -> y * 2

bar = x # refers to the "x" function
x 3 # calls the "x" function with argument 3
x(3) # calls the "x" function with argument 3

So with CoffeeScript there's never a conflict.

-- 
/Jacob Carlborg

On 2013-02-04 08:48, Mehrdad wrote:

> How many of those languages allow you to:
>
> 1. Pass things by reference
>
> 2. Take addresses of expressions

In Ruby and CoffeeScript none of these are allowed. Everything is passed by reference by default but I assume you mean explicitly.

-- 
/Jacob Carlborg

On Monday, 4 February 2013 at 10:06:37 UTC, Jacob Carlborg wrote:
> In CoffeeScript it's only legal to call a function without parentheses if it takes at least one argument. Example:
>
> foo = -> console.log "asd"
>
> bar = foo # refers to the "foo" function
> bar = foo() # calls the "foo" function
>
> x = (y) -> y * 2
>
> bar = x # refers to the "x" function
> x 3 # calls the "x" function with argument 3
> x(3) # calls the "x" function with argument 3
>
> So with CoffeeScript there's never a conflict.

OK, I missed that (I have to say I don't really know that language and went over it quite quickly). The point that was important to me is that this is not really applicable to D.

On Monday, 4 February 2013 at 08:02:20 UTC, Jonathan M Davis wrote:
> On Monday, February 04, 2013 04:34:32 deadalnix wrote:
>> 3/ Haskell
>> 
>> In haskell, all functions are pure, which make the conflation
>> between the function and its result possible in an unambiguous
>> manner.
>
> Haskell doesn't even really have variables per se. It's more like they're
> functions with no arguments. The functional world - especially a purely
> functional world - is a very different place from that of a systems programming
> language. And there are no parens on functions in haskell of any kind to begin
> with. The syntax isn't C-like at all. So, I don't think that it's really a
> valid comparison. The real question is what's happened with C-like languages
> that have attempted to make parens on function calls optional. I don't know
> enough about the other languages that you list though to say whether they
> would qualify.
>

Yes, in such language, you'll find no difference between a function and a variable. It does work because everything is pure and immutable.

The point is that it does not apply to D.

On 02/04/2013 04:34 AM, deadalnix wrote:
> ...
>
> 2/ Scala.
>
> In scala, the method name is evaluated to the method itself. If this
> ends up being a NOOP, then the function is evaluated. See example below :
> ...

That is an inaccurate description of how it works. Methods are called implicitly unless they:

1. Are called explicitly.
2. They are suffixed with _.
3.-n. They occur in a context where a parameter-less function is explicitly requested.

>
> It seems that none does what D try to achieve.

Play around with Scala some more. It does everything D tries to achieve regarding implicit calls, and more.

On 02/04/2013 09:01 AM, Jonathan M Davis wrote:
> On Monday, February 04, 2013 04:34:32 deadalnix wrote:
>> 3/ Haskell
>>
>> In haskell, all functions are pure, which make the conflation
>> between the function and its result possible in an unambiguous
>> manner.
>
> Haskell doesn't even really have variables per se.

That is inaccurate.

> It's more like they're functions with no arguments.

A lambda function always has exactly one argument.

> ...
> And there are no parens on functions in haskell of any kind to begin
> with. The syntax isn't C-like at all.
> ...

s x y z = ((x z) (y z)) -- note the parens

On 02/04/2013 04:26 PM, Timon Gehr wrote:
> On 02/04/2013 09:01 AM, Jonathan M Davis wrote:
>> On Monday, February 04, 2013 04:34:32 deadalnix wrote:
>>> 3/ Haskell
>>>
>>> In haskell, all functions are pure, which make the conflation
>>> between the function and its result possible in an unambiguous
>>> manner.
>>
>> Haskell doesn't even really have variables per se.
>
> That is inaccurate.
>
>> It's more like they're functions with no arguments.
>
> A lambda function always has exactly one argument.
>

s/argument/parameter/g

>> ...
>> And there are no parens on functions in haskell of any kind to begin
>> with. The syntax isn't C-like at all.
>> ...
>
> s x y z = ((x z) (y z)) -- note the parens
>
>