February 04, 2013
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.

February 04, 2013
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
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr



February 04, 2013
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
February 04, 2013
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
February 05, 2013
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
February 05, 2013
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
February 05, 2013
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.
February 05, 2013
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.
February 05, 2013
Ary Borenszweig wrote:
> 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....
>>
> 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.
> 
	Like I said, it is not ambiguous for the computer, but it is for
the developper.

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr



1 2
Next ›   Last »