www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is the compiler supposed to accept this?

reply "Brian Schott" <briancschott gmail.com> writes:
While finishing up work on my parser and grammar specification I 
found this in container.d:

return equal!(function(Elem a, Elem b) => !_less(a,b) && 
!_less(b,a))
                      (thisRange, thatRange);

It seems to be some strange hybrid of the function literal syntax 
and the lambda syntax. It's not documented anywhere (surprise!) 
and I'm not sure if I should support it or file an 
accepts-invalid bug against DMD.
Jul 09 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/10/2013 01:24 AM, Brian Schott wrote:

 While finishing up work on my parser and grammar specification I found
 this in container.d:

 return equal!(function(Elem a, Elem b) => !_less(a,b) && !_less(b,a))
                       (thisRange, thatRange);

 It seems to be some strange hybrid of the function literal syntax and
 the lambda syntax.


=>... is supposed to be just a shorthand for { return ...; }


 It's not documented anywhere (surprise!) and I'm not
 sure if I should support it or file an accepts-invalid bug against DMD.



I'd say support it and file a bug against the documentation.
Jul 09 2013
prev sibling next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
There are severel comments in the part of the dmd front end that 
show the syntax that the parser is looking for. Here's a listing:

// function type (parameters) { statements... }
// delegate type (parameters) { statements... }
// function (parameters) { statements... }
// delegate (parameters) { statements... }
// function { statements... }
// delegate { statements... }
// (parameters) { statements... }
// { statements... }
// identifier => expression

Based on the fact that "function (parameters) => expression" 
isn't written out like the others, I'm going to file an 
accepts-valid bug for this.
Jul 10 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/10/2013 07:47 PM, Brian Schott wrote:

 There are severel comments in the part of the dmd front end that show
 the syntax that the parser is looking for. Here's a listing:

 // function type (parameters) { statements... }
 // delegate type (parameters) { statements... }
 // function (parameters) { statements... }
 // delegate (parameters) { statements... }
 // function { statements... }
 // delegate { statements... }
 // (parameters) { statements... }
 // { statements... }
 // identifier => expression

 Based on the fact that "function (parameters) => expression" isn't
 written out like the others, I'm going to file an accepts-valid bug for
 this.


Accepts-valid is not a bug.
Jul 10 2013
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Wednesday, 10 July 2013 at 18:17:07 UTC, Timon Gehr wrote:

 Accepts-valid is not a bug.


I think you know what I meant. :-)
Jul 10 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/10/2013 08:47 PM, Brian Schott wrote:

 On Wednesday, 10 July 2013 at 18:17:07 UTC, Timon Gehr wrote:

 Accepts-valid is not a bug.


 I think you know what I meant. :-)


Well, I am going to guess you meant accepts-invalid, though I'd prefer 
if you didn't. :o)
Jul 10 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/10/2013 07:47 PM, Brian Schott wrote:

 There are severel comments in the part of the dmd front end that show
 the syntax that the parser is looking for. Here's a listing:

 // function type (parameters) { statements... }
 // delegate type (parameters) { statements... }
 // function (parameters) { statements... }
 // delegate (parameters) { statements... }
 // function { statements... }
 // delegate { statements... }
 // (parameters) { statements... }
 // { statements... }
 // identifier => expression

 Based on the fact that "function (parameters) => expression" isn't
 written out like the others,


You mean, like some others.


 I'm going to file an [...] bug for this.


// (parameters) => expression ?

In any case, please consider that it actually makes no sense to restrict 
the expressiveness of the type signature based on how the function body 
is specified. (Why on earth should one have to use the { return 
expression; } syntax just in order to be able to assert that no context 
pointer is required?)

The documentation is in error here.
Jul 10 2013
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Wednesday, 10 July 2013 at 21:16:30 UTC, Timon Gehr wrote:

 // (parameters) => expression ?

 In any case, please consider that it actually makes no sense to 
 restrict the expressiveness of the type signature based on how 
 the function body is specified. (Why on earth should one have 
 to use the { return expression; } syntax just in order to be 
 able to assert that no context pointer is required?)

 The documentation is in error here.


"(parameters) => expression" is mentioned in the source and I 
agree it's valid. I must have forgotton to copy-paste it.

I don't agree that "function(parameters) => expression" is valid 
though. Can any of the DMD devs clear up if this is intended?
Jul 10 2013
next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 07/10/2013 02:32 PM, Brian Schott wrote:

 On Wednesday, 10 July 2013 at 21:16:30 UTC, Timon Gehr wrote:

 The documentation is in error here.


 "(parameters) => expression" is mentioned in the source and I agree it's
 valid. I must have forgotton to copy-paste it.

 I don't agree that "function(parameters) => expression" is valid though.
 Can any of the DMD devs clear up if this is intended?


According to spec "function(parameters) => expression" is not valid.

   http://dlang.org/expression.html

Lambda:
     Identifier => AssignExpression
     ParameterAttributes => AssignExpression

Neither of those allow 'function' or 'delegate' keyword. However, I 
agree with Timon Gehr that the spec should be changed to match the 
current behavior.

Ali
Jul 10 2013
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/10/2013 11:32 PM, Brian Schott wrote:

 On Wednesday, 10 July 2013 at 21:16:30 UTC, Timon Gehr wrote:

 // (parameters) => expression ?

 In any case, please consider that it actually makes no sense to
 restrict the expressiveness of the type signature based on how the
 function body is specified. (Why on earth should one have to use the {
 return expression; } syntax just in order to be able to assert that no
 context pointer is required?)

 The documentation is in error here.


 "(parameters) => expression" is mentioned in the source and I agree it's
 valid. I must have forgotton to copy-paste it.

 I don't agree that "function(parameters) => expression" is valid though.


Yes, you said that. What I do not understand is why. I think common 
sense would mandate that it should be valid syntax.


 Can any of the DMD devs clear up if this is intended?


This is the relevant pull:

https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Jul 10 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 10 July 2013 at 21:33:00 UTC, Brian Schott wrote:

 On Wednesday, 10 July 2013 at 21:16:30 UTC, Timon Gehr wrote:

 // (parameters) => expression ?

 In any case, please consider that it actually makes no sense 
 to restrict the expressiveness of the type signature based on 
 how the function body is specified. (Why on earth should one 
 have to use the { return expression; } syntax just in order to 
 be able to assert that no context pointer is required?)

 The documentation is in error here.


 "(parameters) => expression" is mentioned in the source and I 
 agree it's valid. I must have forgotton to copy-paste it.

 I don't agree that "function(parameters) => expression" is 
 valid though. Can any of the DMD devs clear up if this is 
 intended?


I don't see how DMD implementation matters here. This is language 
design issue.
Jul 10 2013
prev sibling next sibling parent Kenji Hara <k.hara.pg gmail.com> writes:
This is accepts-valid behavior.

function(parameters) => expr

means the combination of:

1. specifying "context pointer is not necessary"
2. lambda syntax "(parameters) => expr"

I think website documentation has a bug.

Kenji Hara



2013/7/10 Brian Schott <briancschott gmail.com>


 While finishing up work on my parser and grammar specification I found
 this in container.d:

 return equal!(function(Elem a, Elem b) => !_less(a,b) && !_less(b,a))
                      (thisRange, thatRange);

 It seems to be some strange hybrid of the function literal syntax and the
 lambda syntax. It's not documented anywhere (surprise!) and I'm not sure if
 I should support it or file an accepts-invalid bug against DMD.
Jul 10 2013
prev sibling parent reply Kenji Hara <k.hara.pg gmail.com> writes:
I filed the website bug in bugzilla, and posted pull request.

http://d.puremagic.com/issues/show_bug.cgi?id=10605
https://github.com/D-Programming-Language/dlang.org/pull/351

Kenji Hara


2013/7/11 Kenji Hara <k.hara.pg gmail.com>


 This is accepts-valid behavior.

 function(parameters) => expr

 means the combination of:

 1. specifying "context pointer is not necessary"
 2. lambda syntax "(parameters) => expr"

 I think website documentation has a bug.

 Kenji Hara



 2013/7/10 Brian Schott <briancschott gmail.com>


 While finishing up work on my parser and grammar specification I found
 this in container.d:

 return equal!(function(Elem a, Elem b) => !_less(a,b) && !_less(b,a))
                      (thisRange, thatRange);

 It seems to be some strange hybrid of the function literal syntax and the
 lambda syntax. It's not documented anywhere (surprise!) and I'm not sure if
 I should support it or file an accepts-invalid bug against DMD.
Jul 10 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 11 July 2013 at 04:59:14 UTC, Kenji Hara wrote:

 I filed the website bug in bugzilla, and posted pull request.

 http://d.puremagic.com/issues/show_bug.cgi?id=10605
 https://github.com/D-Programming-Language/dlang.org/pull/351

 Kenji Hara


http://msalvarez1.edublogs.org/files/2010/01/rock_rule2.jpg
Jul 11 2013