www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - optional (), what is done elsewhere

reply "deadalnix" <deadalnix gmail.com> writes:
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:2
1: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.
Feb 03 2013
next sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
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

?
Feb 03 2013
parent Jacob Carlborg <doob me.com> writes:
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
Feb 04 2013
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Feb 04 2013
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Feb 04 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/04/2013 04:09 PM, deadalnix wrote:

 ...

 Yes, in such language, you'll find no difference between a function and
 a variable.


Not sure what you are saying.


 It does work because everything is pure and immutable.
...


The important keyword is lazy.
Feb 04 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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
Feb 04 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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
Feb 04 2013
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, February 04, 2013 16:26:37 Timon Gehr wrote:

 ...
 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


Which aren't doing function calls. They're only applying precedence.

- Jonathan M Davis
Feb 04 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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

   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"




x = (y) -> y * 2





So with CoffeeScript there's never a conflict.

-- 
/Jacob Carlborg
Feb 04 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
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"




 x = (y) -> y * 2





 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.
Feb 04 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-04 16:08, deadalnix wrote:


 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.


I think it's important to the reason why these languages don't have any 
problems with optional parentheses and why D do have. Otherwise I think 
this whole thread is kind of pointless.

-- 
/Jacob Carlborg
Feb 04 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 5 February 2013 at 07:14:49 UTC, Jacob Carlborg wrote:

 On 2013-02-04 16:08, deadalnix wrote:


 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.


 I think it's important to the reason why these languages don't 
 have any problems with optional parentheses and why D do have. 
 Otherwise I think this whole thread is kind of pointless.


Yes, this is why I went quickly over cofeescript : it is clearly 
not at all the same thin as D.

Now I think the most relevant one is scala here.

So in scala, funName is a polysemic expression : it is either the 
function or the function's result after evaluation. Scala get 
from context which one make sense.

The major difference I see with scala are :
  - You have no unary & operator to get address of. Confusion in 
that regard is completely avoided.
  - You don't have an intermediate with unexplainable type between 
a function definition and a function (like in C/C++). D try to 
work around that in a poor way. Scala totally remove that concept 
from the language, as it is a source of trouble without any 
usefulness.

The main question I ask myself is how that behavior would 
interact with other D features.
Feb 05 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/05/2013 09:17 AM, deadalnix wrote:

 On Tuesday, 5 February 2013 at 07:14:49 UTC, Jacob Carlborg wrote:

 On 2013-02-04 16:08, deadalnix wrote:


 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.


 I think it's important to the reason why these languages don't have
 any problems with optional parentheses and why D do have. Otherwise I
 think this whole thread is kind of pointless.


 Yes, this is why I went quickly over cofeescript : it is clearly not at
 all the same thin as D.

 Now I think the most relevant one is scala here.

 So in scala, funName is a polysemic expression : it is either the
 function or the function's result after evaluation. Scala get from
 context which one make sense.

 The major difference I see with scala are :
   - You have no unary & operator to get address of. Confusion in that
 regard is completely avoided.


You have suffix _ which has a similar role, however it is not overloaded 
to take raw field addresses.


   - You don't have an intermediate with unexplainable type between a
 function definition and a function (like in C/C++). D try to work around
 that in a poor way. Scala totally remove that concept from the language,
 as it is a source of trouble without any usefulness.


The only trouble is that there is no use. We definitely should get rid 
of that. (Don't allow dereferencing function pointers, together with the 
sane parts of DIP23.)


 The main question I ask myself is how that behavior would interact with
 other D features.


The broken is(T==function) would cease to do anything of use.
Feb 05 2013
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Feb 04 2013
prev sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
deadalnix wrote:

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


	Note that in Ruby, this line:

foo(1, 2)

	Means something different than:

foo (1, 2)

	That may not be ambiguous for the computer, but it sure is for the
programmer....

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Feb 04 2013
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 2/4/13 2:10 PM, "Jérôme M. Berger" wrote:

 deadalnix wrote:

 1/ Ruby.

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


 	Note that in Ruby, this line:

 foo(1, 2)

 	Means something different than:

 foo (1, 2)

 	That may not be ambiguous for the computer, but it sure is for the
 programmer....

 		Jerome


irb(main):001:0> foo (1, 2)
SyntaxError: (irb):1: syntax error, unexpected ',', expecting ')'
foo (1, 2)
        ^

Not ambiguous at all, it's a syntax error because (a, b) is not a valid 
expression.

Ruby is... perfect :-P
Feb 04 2013
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Ary Borenszweig wrote:

 On 2/4/13 2:10 PM, "J=C3=A9r=C3=B4me M. Berger" wrote:

 deadalnix wrote:

 1/ Ruby.

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


 	Note that in Ruby, this line:

 foo(1, 2)

 	Means something different than:

 foo (1, 2)

 	That may not be ambiguous for the computer, but it sure is for the
 programmer....


 irb(main):001:0> foo (1, 2)
 SyntaxError: (irb):1: syntax error, unexpected ',', expecting ')'
 foo (1, 2)
         ^
=20
 Not ambiguous at all, it's a syntax error because (a, b) is not a valid=


=20

 expression.
=20


	Like I said, it is not ambiguous for the computer, but it is for
the developper.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Feb 05 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-04 18:10, "Jérôme M. Berger" wrote:

 deadalnix wrote:

 1/ Ruby.

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


 	Note that in Ruby, this line:

 foo(1, 2)

 	Means something different than:

 foo (1, 2)

 	That may not be ambiguous for the computer, but it sure is for the
 programmer....


For Ruby 1.8.7 I get this result:

[1] pry(main)> def foo (a, b); p a; end
=> nil
[2] pry(main)> foo(1, 2)
1
=> nil
[3] pry(main)> foo (1, 2)
(pry):3: warning: don't put space before argument parentheses
1
=> nil

I get a warning but I do get the same result. Using Ruby 1.9.x it's as 
Ary said, it's a syntax error.

-- 
/Jacob Carlborg
Feb 04 2013